Guide
Website migration SEO checklist: protect what already ranks
A website migration SEO checklist comes down to five jobs: list every old URL that earns traffic, links or leads, redirect each one to its closest new page, test the new site on staging before anyone sees it, point canonicals, sitemaps and internal links at the new URLs, then watch Search Console and your enquiries until things settle. Get the whole move handed over in writing, so nothing is lost between the developer and whoever looks after your SEO.
What kind of move are you making?
Name the move first, because each type needs different checks. A redesign that keeps every URL is the lowest-risk change. Anything that changes URLs, the domain or the protocol needs a redirect map. A move to a new host that keeps the same URLs needs no redirects at all, but it still needs testing.
A platform change, such as leaving a hosted site builder for WordPress or a custom build, usually changes URLs even when nobody planned to, because each platform has its own address patterns. Compare a sample of old and new addresses early. Look for folders the new system forces, such as /blog/ or /services/, a trailing slash added or dropped, category and tag archives that appear or vanish, and images that move to a new media path. Plugins often write their own canonical tags and redirects, so find out which tool owns each one before launch, or two tools will fight over the same URL.
Search Console Help limits the Change of Address tool to moves between domains or subdomains. It isn't used for a switch from http to https, a www change, or new paths on the same domain.
| Type of move | Do URLs change? | Redirect map needed? | Change of Address tool? |
|---|---|---|---|
| New design, same URLs | No | Only for pages you merge or replace | No |
| New platform or CMS | Usually, even when the plan says they won't | Yes, for every changed URL, files included | No, unless the domain changes too |
| New URL structure, same domain | Yes | Yes, for every changed URL | No |
| New domain or subdomain | Yes | Yes, for every URL | Yes |
| http to https, or www to non-www | Yes | Yes, as a site-wide rule | No |
| New host or CDN, same URLs | No | No | No |
Build the URL inventory and baseline before the build starts
The inventory is the list of every old URL worth protecting, and it has to exist before anyone deletes a page. Google's site move guide suggests starting with your sitemaps, your server logs or analytics for the pages with the most traffic, and Search Console for pages other sites link to. The Links report in Search Console shows your top linked pages and can be exported as a CSV file or a Google Sheet, according to Search Console Help.
Then add the URLs people reach from outside the site. They're easy to miss: the website link on your Google Business Profile, Google Ads final URLs, QR codes on vans and flyers, email signatures, and PDFs such as price lists or safety documents. A crawl of the live site fills in the rest. Record each URL in a spreadsheet with its status code, its clicks, whether other sites link to it, the decision (keep, redirect, merge or remove) and, once the new page list is fixed, its new URL.
The inventory tells you what to protect. The baseline tells you, after launch, whether the new site is actually doing worse, and Search Console clicks alone won't show that. Save these before anything changes, and date every export:
| Baseline measure | Where to get it | Why it matters after launch |
|---|---|---|
| Clicks and impressions per page | Search Console Performance report, Pages tab, over a long date range | Shows which pages earned search traffic and lets you compare each one week by week |
| Pages other sites link to | Search Console Links report, top linked pages | These URLs need a redirect even when their own traffic is quiet |
| Leads per page | GA4 key events for form sends and call clicks, by landing page, plus your call tracking records | Tells you whether the new site converts worse, which rankings alone never show |
| Positions for your money terms | A fixed list of service and suburb searches, checked the same way before and after | Spots a drop on one service before it shows up in site totals |
| Page experience | Search Console Core Web Vitals report, plus a speed test of your main page templates | Shows whether the new build is slower for real visitors |
| A full copy of the old site | A host backup of files and database, plus a crawler export of each page's title, description, H1 and copy | Your reference for content checks and your way back if launch goes wrong |
Map every redirect to its closest match
Use server-side permanent redirects (301 or 308) wherever your host allows. Google's redirects documentation says to use a permanent server-side redirect whenever possible, and to use JavaScript redirects only when server-side and meta refresh redirects aren't possible. Don't use temporary redirects (302 or 307) for a move. The same documentation says Google uses a permanent redirect as a signal that the target should be canonical, but doesn't treat a temporary one that way, so the old URL can keep showing in results.
Point each redirect straight at its final page. Googlebot can follow up to 10 hops, but Google advises redirecting directly to the final destination, and where a chain can't be avoided, keeping it under 5 hops, ideally no more than 3. Chains usually come from an earlier rebuild, so fold any old redirects into the new map.
Files count too. Google's guide says images, videos, JavaScript and CSS files need to move the same way pages do, so a job photo that shows in image search or a PDF with links gets its own row. If two old pages are really one topic, the guide on when to merge overlapping pages helps you pick the keeper. Load the finished map onto staging and run the whole old URL list through it before launch day, so the first test isn't the live one.
Every row in the inventory ends in one of these outcomes:
- Same content, new address: a permanent redirect to the new page.
- Several old pages merged into one: redirect each of them to the merged page. Google's site move guide allows this for consolidated content.
- Content dropped with no close match: let the old URL return a 404 or 410. Google warns that sending many old URLs to one unrelated page, such as the home page, can confuse people and may be treated as a soft 404.
- Same URL on the new site: no redirect needed. Just check the new page still covers what the old one did.
Test the staging site before launch
Run a full test pass on staging before launch day, page by page against your backup. Most crawlers can sign in to a password-protected staging site or be told to ignore its robots.txt block, so crawl it the same way you crawled the live site and compare the two exports side by side. A rebuilt page that loses half its copy, its suburb names or its FAQs is a weaker page, even at the right URL.
Keep staging behind a login the whole time. Google says robots.txt is not a way to keep a page out of Google, and that password protection is how you keep private content out. Google's canonical documentation rates redirects and rel="canonical" tags as strong signals and sitemap inclusion as a weak one, and warns against naming different canonicals through different methods, so the canonical, sitemap and internal link checks below all need to agree. The guide to noindex, canonical and redirects explains when each one is the right tool.
Keep canonicals, sitemaps and internal links on the new URLs. Google's site move guide says each new URL should carry a self-referencing rel="canonical" tag, and Google's canonical documentation advises absolute rather than relative URLs, so every page names itself with its full new address. Update menus, footers and in-content links from the redirect map so they point straight at the new URLs instead of leaning on redirects. Build the XML sitemap from new URLs only. Then remove any noindex rules and robots.txt blocks that were only needed during development, as the guide reminds site owners to do.
Check these elements on every page that earns traffic, links or leads, and don't launch until every row passes:
| Element | What to compare | Fix it before launch if |
|---|---|---|
| Title and meta description | Old export against the new page source | Titles are blank, duplicated across pages or reset to a template default |
| H1 and body copy | Headings, service details, suburb names, FAQs | Content was cut or replaced with placeholder text |
| Images | File names, alt text, whether job photos still load | Alt text is missing or photos point at the old media path |
| Structured data | Business details and FAQ markup, tested with Google's Rich Results Test | Markup is missing, invalid or describes content the page no longer shows |
| Canonical tag | Each page names itself with its full new URL | It points at the old domain, the staging address or a URL that redirects |
| Internal links | Menus, footers and in-content links | Links point at old URLs that redirect, or at staging |
| XML sitemap | Only new URLs you want in search, as full URLs | It lists redirecting, staging or noindexed URLs |
| Phone, address and forms | Every number, address and form on the page | Anything differs from your Business Profile, a test send misses the right inbox or the thank-you page fails to load |
| Tap-to-call links | Every phone link, dialled from a mobile | A link dials the wrong number or a tracking number nobody has mapped to its source |
| Analytics | GA4 form and call key events, checked in Realtime after test sends (GA4 Help says Realtime updates a few minutes after a key event) | The events don't record |
| robots.txt and noindex | The launch robots.txt, prepared in advance, and the robots meta tag on every template | The launch file would still block all crawling, or a development noindex rule sits on a live template |
| Redirect map and backup | The whole old URL list run through the redirects on staging, plus a dated backup of the old site | Any old URL fails its redirect test, or no backup exists |
| Hosting capacity | The new host's plan, because Google's site move guide says it will temporarily crawl a moved site more heavily than usual | Nobody has checked the host can carry the extra load |
Migration timeline and launch day
Run the move as one planned cutover with fixed stages. Google's site move guide recommends moving all URLs at the same time for small and medium sites, which covers most local service business sites; only large sites gain much from moving one section at a time. The inventory, baseline and backup come first because they can't be rebuilt once old pages are gone, and listing updates wait until the new URLs are live and redirecting.
Pick the launch date for traffic, not convenience. Google's site move guide says to time the move for lower traffic where possible, and if your traffic is seasonal or dips on certain weekdays, to move during those dips. Launch on a day when the developer and the person who checks the leads are both working, and freeze other changes for the first few weeks: no new pages, no ad changes, no theme updates. If three things change at once, nobody can tell which one moved the numbers.
Agree a rollback rule in writing before launch. A sensible one: if a fault blocks crawling site-wide or stops leads arriving, and it can't be fixed the same day, restore the old site from the backup while it's fixed. A single weak page gets fixed forward instead.
Launch day is one stage in a longer sequence. Each row below is a set of tasks to finish in that stage, not a forecast of how long recovery takes:
| When | Tasks |
|---|---|
| Before the build | URL inventory, baseline exports, backup, agree who owns redirects and the handover |
| Before launch | Staging crawl, content checks, redirect map test, form and call tests, launch robots.txt ready |
| Launch day | Switch over, run every old URL through a redirect checker, check robots.txt, noindex and canonicals on the live site, submit the new sitemap (the old one can then be removed), test leads again |
| Launch week | Update the Business Profile website link, Google Ads final URLs, social profiles and other [business listings](/resources/business-listing-accuracy/); file Change of Address if the domain changed |
| First two months | Weekly comparison with the baseline, Page indexing report, server logs, backlink update requests |
| Ongoing | Keep redirects running and the old domain renewed; monthly reporting against the baseline |
Monitor the move and diagnose a drop
Expect some movement. Google's site move guide says visibility may fluctuate while pages are recrawled, and that for a medium-sized site it can take a few weeks or more before Google shows the new URLs in place of the old ones. Check weekly for the first couple of months, comparing each page's clicks, impressions and leads with your baseline. The guide also suggests using analytics to compare traffic on the old and new sites, and watching your server logs for Googlebot's crawling and for URLs that unexpectedly return errors.
When traffic falls, work out what kind of drop it is before changing anything. First, check whether only organic search fell. If every channel dropped on launch day, including direct and paid, the analytics tag is probably missing from the new templates and the site may be fine. Next, check whether it's site-wide or page by page. A site-wide fall points at a shared cause: a noindex rule, a robots.txt block, canonicals naming staging, or a redirect rule that sends everything home. A fall on a few pages points at a missed redirect or a thinner replacement page, so compare those pages with the backup copy. Finally, split rankings from leads. If impressions and clicks hold but enquiries fall, the problem is the forms, the phone numbers or the tracking, and the call tracking and conversion reconciliation guide shows how to check the numbers line up.
Keep the old domain registered and the redirects running well after the graphs settle. A monthly SEO report should show pre-launch and post-launch figures side by side until they do.
Read the Page indexing report and URL Inspection results against this table:
| What you see | What it usually means | What to do |
|---|---|---|
| Not found (404) on URLs that had traffic or links | A row missing from the redirect map | Add the redirect, then inspect the URL again |
| Soft 404 | A page that looks empty or like an error but returns a 200, or many old URLs sent to one unrelated page | Redirect to a closer match, or return a real 404 |
| Redirect error | A chain that's too long, a loop or a bad target URL | Point the old URL straight at the final page |
| Duplicate, Google chose different canonical than user | Mixed signals, often a canonical, sitemap or link still naming an old or staging URL | Compare the user-declared and Google-selected canonical in URL Inspection, then line the signals up |
| Excluded by noindex tag on new pages | A development setting that went live | Remove the rule from the template, then request indexing for key pages |
Worked example: a Caloundra plumber's move and handover
Say a plumbing business in Caloundra is leaving a hosted site builder for WordPress on the same domain. Its suburb pages sit at addresses like /blocked-drains-caloundra/, and the new site files them under /plumbing/blocked-drains/caloundra/. The figures below are illustrative only.
Step 1, inventory. A crawl of the live site finds 60 URLs. The Search Console Links report adds two old blog posts the crawl missed because no menu links to them any more, and the owner remembers a QR code on the van that points to /book-online/. Every one gets a row, even the quiet ones, because another site may still link to it.
Step 2, decisions. Each suburb page redirects one to one to its new address. Two thin posts about drain cameras are merged into the new drains guide and both redirect there. An expired winter promotion has no close match, so it returns a 410 instead of redirecting to the home page. The QR code URL redirects to the new booking page, so the van doesn't need a new wrap.
Step 3, staging test. The crawl comparison shows the new SEO plugin sets every canonical to the staging address, job photos still load from the old builder's media path, and the quote form sends to the developer's test inbox. All three are fixed and retested before the launch date is confirmed.
Step 4, launch and follow-up. The site goes live on a weekday morning in a quieter month, with the developer on hand. In week one the owner updates the Business Profile link and emails the two sites with the most links, from the Links report, with a short request: "Thanks for linking to our blocked drains page. We've moved to a new website and that page now has a new address (new link below). Could you update it when you next edit your page? The old link redirects, so nothing is broken in the meantime."
Step 5, handover. Before the final invoice is paid, the owner asks the developer for a handover pack. Ownership matters most here. Search Console has owners, full users and restricted users, and owners can add or remove anyone else, so the business should be an owner and outside helpers can be users. If you remove a verified owner, Search Console Help says to delete their verification tokens as well, or they can verify again. If you're paying someone to run the move, this list doubles as the scope, and what an SEO audit should deliver helps you judge the findings they hand back. The pack should hold:
- The URL inventory and redirect map, as a spreadsheet you can open, with the result of the launch-day redirect test against each row
- Where the redirects live (server settings, a CMS plugin, the host or CDN) and who can edit them
- The dated baseline: the crawl, the Search Console and GA4 exports, the backup location and the launch date
- Known issues, anything deliberately left out of the move, and the rollback rule that applied
- A short results note after the first two months comparing traffic, indexing and leads with the baseline
- Who is watching the reports after launch, and for how long
- Access to the domain registrar, DNS, hosting, Search Console, Google Analytics, Google Business Profile and Google Ads, all held in the business's own accounts
Common questions
How do I migrate a website without losing SEO?
Protect what already earns traffic before anything changes, then keep every signal pointing at the new URLs. List every old URL with traffic, links or leads, permanently redirect each one to its closest new page, and test the new site on staging. After launch, compare Search Console and enquiries with a saved baseline. No one can guarantee a move without any dip, and Google's site move guide says rankings may fluctuate for a while as pages are recrawled.
What is an SEO migration?
An SEO migration is any website change that can affect how search engines find, crawl and rank the site, managed so its existing rankings and traffic carry over. Google's site move documentation covers moves that change URLs, such as a new domain, an http to https switch or a new URL structure, and moves that keep the URLs but change hosting. A redesign or new CMS counts too when it changes URLs, templates or content.
What should a website migration SEO checklist include?
It should cover five jobs in order. Inventory every old URL that earns traffic, links or leads, and save a dated baseline. Map each one to its closest new page with a permanent redirect. Test the new site on staging for content, canonicals, internal links, the sitemap, forms and phone numbers. Launch with development crawl blocks removed and the new sitemap submitted. Then monitor Search Console, analytics and enquiries against the baseline, and get the handover in writing.
How long should I keep 301 redirects after a migration?
Keep them for as long as you can, and for at least a year. Google's site move guide says to keep redirects generally for at least 1 year so signals can pass to the new URLs, and suggests keeping them indefinitely for visitors' sake. For a domain change, Search Console Help says at least 180 days, and longer while Google Search still sends traffic to the old URLs. Keep renewing the old domain too.
Do I need the Change of Address tool in Search Console?
Only if you're moving to a different domain or subdomain, such as oldname.com.au to newname.com.au. The same Google account must be an owner of both properties, and the old home page must 301 redirect to the new one. The tool doesn't move subdomains below the domain you name, www included, so file for each variant of the old domain, including www and non-www. The request stays in effect for 180 days.
Do I need to update my Google Business Profile after changing websites?
Yes, if the website address changed. Edit the website link in your Business Profile and enter the full URL, including https. Google's Business Profile Help says changes are reviewed before they appear, so check back that the new link shows. Check any appointment or booking links as well, so nobody lands on a redirect or a dead page. The Google Business Profile audit checklist covers the other fields worth rechecking.
Is it normal for Search Console to show old pages as 'Page with redirect'?
Yes. Search Console Help describes a page with redirect as a non-canonical URL that redirects to another page, so it won't be indexed. That's the result you want for old URLs after a move. Check a sample in URL Inspection anyway: each redirect should land on the right page in one hop, and the new page should be indexed in its place.
What if I'm changing hosts but keeping the same URLs?
Treat it as a move without URL changes, so there are no redirects and no Change of Address request. Google's guidance is to copy the site to the new host, test it on a temporary hostname, lower your DNS TTL at least a week ahead, then remove temporary crawl blocks and switch the DNS. Keep the old hosting until its traffic reaches zero. Google says a temporary drop in Googlebot's crawl rate right after launch is normal, followed by a steady increase over a few days.
