Use a scratch domain to test a migrated site

Why a scratch domain

A scratch domain is a separate, unimportant domain you point at the new host to preview the site there before the real domain's DNS changes. It lets you verify the migrated site works, without routing any real visitors to the new infrastructure or breaking the live site. It is the link between a purely local check and a full host migration, and it acts as the preview surface for the staging to live flow.

The core benefit is time and safety: you can load pages, test the admin, and exercise the parts of the site that only render under a matching hostname, all while the production domain stays untouched. You inspect the new host under the scratch name, fix what is wrong, and only then repoint the real domain.

Set it up

1. Pick a scratch domain you control. It can be a subdomain on an existing domain (for example preview.example.com), or a cheap throwaway domain. What matters is that you can set its DNS records yourself and that no real traffic depends on it.
2. Point it at the new host. Add an A record for the scratch hostname pointing at the new server's IP (or whatever the new host expects, such as a CNAME to its preview host). This must be a hostname that terminates at the new origin, not one that proxies through the live site.
3. Verify HTTPS works on the scratch name. Many hosts provision or attach a certificate, and WordPress is generally fine serving under the scratch name, but you may need a certificate covering preview.example.com if the site or its mixed content rules reject it. Do not let a scratch-domain HTTPS failure hide a real issue. The SSL reissue during migration guide covers the certificate side of changing hosts.
4. Preview the site. Load the home page, internal pages, the admin, and resources under the scratch URL. Because the site is on the new infrastructure, test what actually changed: file paths, database content and hostname references. Use the status code diff audit to compare old and new behaviour under the scratch hostname.

Pitfalls to handle

• Redirects that force the real domain. If the site is configured to redirect any hostname to the canonical live domain (via the WordPress siteurl and home or a server-level rule), the scratch domain will bounce straight back to the live site and you cannot preview the new host. Temporarily neutralise that redirect or set the site URL to the scratch host so the preview actually renders on the new server.
• Hard-coded absolute URLs. Content and settings baked with the real domain will load from the live origin even while you are on the scratch host, which can make the preview look correct for all the wrong reasons. The search-replace during migration guidance applies; you mostly want the preview to prove the new host, so fix the genuinely new-host problems and carry the domains decision over to cutover.
• Ports, paths and IP access. If the scratch host is only reachable on a port or requires the panel's IP allow-list, a visitor on the open internet cannot see it. Confirm the scratch hostname is reachable from wherever you will test it, and remember some hosts restrict previews to an IP range.
• Cache from the old host. A panel preview that still answers from the old environment can show stale content, so hard-clear caches and confirm you are hitting the new origin before judging it.

When the scratch preview is clean, cut over the real domain exactly as the DNS cutover describes, keeping the scratch host alive during and after the switch as a comparison surface. The scratch domain is a validation tool, not a destination, so once the live domain is verified the throwaway hostname can be retired. The sequence, preview on a scratch host, fix, repoint the real domain, is what lets you migrate hosting with confidence instead of discovering the faults live.