Create a WordPress Site Without a Domain: Three Routes, One Trap

You do not need a domain to build a WordPress site. There are three working routes: install WordPress locally on your own machine, build on a host-provided temporary URL, or build on a staging subdomain you already control. All three let you finish the site first and decide on the name later. Only one of them makes the eventual move a non-event.

The reason this question comes up so often is that the usual advice has the order backwards. Buy a domain, buy hosting, then start building — which means committing to a name before you have seen the site, and paying for hosting during the weeks when nothing is live. Building first and naming later is the better sequence. The trap is that the route people reach for first is the one with the most painful ending.

The trap, stated first so you can avoid it
Route one: local install
Route two: build on a host-provided temporary URL
Route three: a staging subdomain on a domain you already own
The pre-launch checklist that actually matters
How this plays out on a managed platform
How this fits the rest of the stack
FAQ

The trap, stated first so you can avoid it

WordPress stores its own address in the database. Two options, siteurl and home, hold the URL the site believes it lives at. Plugins, page builders, and the media library then write that URL into content: image src attributes, internal links, serialised option blobs, cached CSS.

So when you move a site from one address to another, you are not moving files. You are performing a find-and-replace across a database in which some of the target strings are inside serialised PHP arrays where a length prefix has to be recalculated. This is why a hand-edited SQL dump produces a site with broken widgets and a page builder that has forgotten its layout.

Every route below is a way of managing that one problem. The local install faces it head-on. The temporary-URL route reduces it. The staging-subdomain route is the only one that can avoid it entirely.

Route one: local install

Install WordPress on your own machine with a local development tool or a classic AMP stack. It is free, it is fast, and it needs no internet connection.

This is genuinely the right route when you are learning WordPress, developing a theme, or testing plugin behaviour. Nobody else needs to see it, so its biggest limitation does not apply.

Its limitations, in order of how much they will annoy you:

Nobody else can see it. A client cannot review it, a colleague cannot check the mobile layout, and you cannot open it on your own phone without extra networking work.
The URL is maximally different from the final one. Moving from localhost:8888 or mysite.local to example.com is the full database rewrite described above.
The environment does not match production. Different PHP version, different limits, no real TLS, mail that goes nowhere. Things that work locally break on the live server for environmental reasons that take a day to isolate.
Backups are your laptop. Which is fine until the laptop is not.

If you take this route, use a tool that has a one-click export or push-to-live feature, and use its migration path rather than a manual SQL dump.

Route two: build on a host-provided temporary URL

Most hosts will give a new WordPress install a temporary hostname on a domain they own — something like random-name.hosting-platform.net — and let you build on that before attaching your own domain.

This is the pragmatic default for most people. The environment is the real one: the actual PHP version, actual limits, actual TLS, actual mail configuration. The site is reachable by anyone you send the link to. And when your domain is ready, you attach it and update the site address, which is one URL change on a site whose content you have complete control over.

Two things to do while building on a temporary URL:

Discourage search engines. In Settings, Reading, tick the option to discourage indexing. It writes a noindex directive, and it keeps the temporary hostname out of search results, which is otherwise a duplicate-content mess you have to clean up later.
Use relative or root-relative links in content where you can. Every absolute link you write to the temporary hostname is a string that has to be rewritten later.

When the domain arrives, the move is: add the custom domain, wait for the certificate, change the site address in WordPress settings, run a search-replace across the database for the old hostname, and check the media library. Use a migration plugin or WP-CLI’s search-replace, which handles serialised data correctly:

wp search-replace 'https://random-name.hosting-platform.net' \
  'https://example.com' --all-tables --precise --recurse-objects

# Dry run first, always
wp search-replace 'old' 'new' --all-tables --dry-run

Route three: a staging subdomain on a domain you already own

If you already own any domain — a personal one, an old project, the company’s existing site — you can build at newsite.example.com and skip most of the pain.

This is the best route when it is available, for a reason that is not obvious: you get a real hostname, real TLS, a shareable link, and a production-equivalent environment, and if the final site is going to live on the same domain, the URL change is small or unnecessary.

The workflow is a DNS record and a custom domain entry. Point newsite.example.com at the deployment, let the certificate issue, and build. When it is ready, either move it to the apex or, if the plan was always a subdomain, you are already done.

The one thing to remember is the same as above: discourage indexing while you build, and remember to turn it off when you launch. A launched site still carrying noindex is one of the most common and most expensive WordPress launch mistakes, because everything looks fine and the traffic simply never arrives.

The pre-launch checklist that actually matters

Whichever route you took, these are the items that cause visible problems on launch day.

Search engine visibility is back on. Settings, Reading. Check the rendered page source for a noindex meta tag before you announce anything.
Site address and WordPress address both updated. Settings, General. A mismatch produces redirect loops and broken admin logins.
Database search-replace completed for the old hostname. Then grep the database for the old string to confirm nothing remains, particularly in wp_postmeta and wp_options.
Media library images load. Open a few older posts. Broken images almost always mean a missed absolute URL.
Permalinks re-saved. Settings, Permalinks, save without changing anything. This regenerates rewrite rules and fixes the classic every-page-404 after a move.
Certificate covers both apex and www, and one redirects to the other consistently.
Mail actually sends. Trigger a password reset. WordPress mail via the local PHP mailer frequently goes straight to spam or nowhere.

How this plays out on a managed platform

The three routes differ mostly in how much environment mismatch you are storing up for later. That framing is why the temporary-URL route wins for most people: it is production, just under a name you do not want yet.

On RunxBuild, a WordPress site gets a working URL as soon as it is created, on a ladder that starts at $3 a month for Starter, so you can build the whole site before you have chosen a name and before you are paying much for the privilege. Two dashboard features are relevant to this specific job: a file manager for browsing, editing, uploading and unzipping files without SFTP, and a database browser for tables, rows, SQL, export and import — which is where the search-replace step happens without needing to install WP-CLI on your own machine.

When the domain is ready, it is a custom domain entry with the certificate handled, then the URL change inside WordPress. The order matters: attach the domain and confirm it serves before you change the site address, or you will lock yourself out of the admin at exactly the wrong moment.

How this fits the rest of the stack

Building before buying is the right order, and the only real question is how much environment mismatch you are prepared to fix later. If you are pricing the site properly, the plan is one number and the traffic is another. The RunxBuild hosting calculator shows the WordPress plan, the storage and the bandwidth as separate line items, which is the shape the bill takes once the domain is finally pointed at it.

Useful related references:

FAQ

Can I build a WordPress site without buying a domain first?

Yes. Install it locally, use a host-provided temporary URL, or build on a subdomain of a domain you already own. All three let you finish the site before choosing a name, and the temporary URL is closest to the final environment.

What is the trap when moving a WordPress site to a new domain?

WordPress writes its own URL into the database, including inside serialised plugin and page-builder data. A plain SQL find-and-replace corrupts those serialised values. Use a migration plugin or WP-CLI search-replace with —recurse-objects instead.

Is a local WordPress install good enough?

It is good for learning, theme work, and plugin testing. It is poor for client review, because nobody else can reach it, and it stores up the largest environment mismatch and the biggest URL rewrite for launch day.

Should I block search engines while building?

Yes, tick the discourage-indexing option in Settings, Reading. Then remember to untick it at launch. A live site still serving noindex is a common and costly launch mistake because nothing looks broken.

Why do all my pages 404 after moving the site?

Rewrite rules did not regenerate. Go to Settings, Permalinks and save without changing anything. If that does not fix it, check that the site address and WordPress address settings both point at the new domain.