Building a WordPress Site Before You Have a Domain
Every route to a domain-less WordPress site writes some URL into the database. The only question that matters is how expensive that URL will be to remove later.
WordPress always has an address. There is no configuration in which it does not — the installer writes one into the database during setup, and every image you upload afterwards is recorded against it. "Without a domain" therefore never means no URL. It means a placeholder URL, and your real decision is which placeholder costs least to undo.
Get that wrong and the site launches with broken images, mixed content warnings and a page builder pointing at an address that no longer exists.
The three routes, and what each one costs
| Route | Address you get | Public while building | Cost to switch |
|---|---|---|---|
| Local install | Something like mysite.local |
No | Low — one clean migration, planned from the start |
| Host's temporary URL | A subdomain of the host, or an IP-based path | Yes | Highest — the URL is baked in everywhere |
| Free subdomain | yourname.provider.com |
Yes | Medium to high, and the address may be hard to leave |
Local development is the honest default
A local environment runs the full stack — PHP, MySQL, a web server — on your own machine. The dedicated WordPress local tools install all of it in one step; general-purpose stacks and container setups do the same with more control and more configuration.
The advantages are real. Nothing is public, so there is no half-finished site for anyone to find and nothing for search engines to index. It is fast, because there is no network in the loop. Breaking it costs nothing. And you can build with the intention of migrating, which is a different mindset from migrating because you have been forced to.
The limitations are equally real. Clients cannot see it. Anything that needs an inbound connection from an external service — payment gateway callbacks, webhooks, some email delivery — will not reach your laptop without extra tunnelling. And you must actually be able to perform the migration at the end.
Pick this route if you are building alone and the site is not urgent.
The temporary URL, and why this article exists
Buy hosting without a domain and most hosts hand you a working address immediately — a subdomain of theirs, or something built from your server's IP address. It works, it is instant, and it is where the trouble starts.
That address is not just a way to reach the site. During installation it is written into the siteurl and home options, and from then on it is stamped into:
- Every uploaded image, as an absolute URL inside the post content;
- Internal links you write between pages;
- Theme and plugin settings that store logos, background images or redirects;
- Page-builder data, which is the worst of them — builders store large structured blobs full of absolute URLs;
- Serialised option values, where each stored string records its own byte length.
That last point is the trap. When the real domain arrives, a naive find-and-replace across the database changes the text but not the recorded lengths, so those values fail to unserialise and silently revert to defaults. You lose settings without any error telling you so. The correct fix is a serialisation-aware search and replace — WP-CLI's search-replace, or an equivalent script — run against every table.
Two mitigations make the temporary route survivable. First, do the switch early: the longer the site lives on the temporary address, the more content accumulates carrying it. Second, keep the site out of the index while it is there, or you launch competing with your own placeholder — the failure mode described in why a site does not appear in Google.
If the site must be visible to a client during the build, this is still the pragmatic choice. Just budget for the search and replace rather than discovering it on launch day.
Free subdomains
A subdomain from a hosted platform gets you online with no cost and no setup. The catch is not the URL — it is that the platform decides what you can install, and a free tier often cannot run arbitrary plugins or themes at all.
Treat it as publishing, not as building. If you are learning WordPress in order to run your own install later, the habits do not fully transfer.
What to do instead, most of the time
Register the domain now. It is the cheapest line item in the entire project, it can point at a holding page until you are ready, and it removes this whole category of problem before it starts. Choosing a name usually takes longer than paying for it.
If you genuinely cannot yet — the name is unresolved, the business is not named, a trademark check is pending — build locally and migrate once.
If the site must be online today on a host's temporary address, then before you write a single post: install on the host in the usual way, turn on search-engine blocking, and put the front end behind a coming-soon or maintenance screen. Then plan the URL change as a task with a date on it, not as something you will get to.
Frequently asked
- Yes, and it is the cleanest of the three routes. The whole install transfers as files plus a database export, and the only change needed on arrival is a serialisation-aware search and replace of the local URL.
- Only if it gets indexed. Keep the site closed to search engines while it is on the temporary address, so the real domain launches without a near-duplicate of itself already in the index competing for the same content.
- Image references in post content are stored as absolute URLs pointing at the old address. Changing the two site options in settings does not touch them, so they keep requesting files from a hostname that no longer serves the site.