A website migration puts every ranking you have earned at risk. The short answer to protecting your SEO is this: benchmark your current site before anything changes, map every old URL to a new one with a 301 redirect, carry across all page titles, meta descriptions and content, keep your staging site hidden from Google, then monitor rankings closely for 90 days after launch. Miss any one of those steps and your organic traffic can drop by half, sometimes for months.
At Digitalzoop, we have watched Sydney businesses come to us after a redesign wiped out rankings that took years to build. In almost every case, the problem was the same. The new website project was run by a designer or developer, and nobody was responsible for the SEO. This guide walks through exactly what needs to happen before, during and after a migration, including two areas most checklists skip entirely: your local search visibility and your presence in AI-generated answers.
What Counts as a Website Migration?
A website migration is any change that alters your URLs, content, structure or hosting in a way that forces Google to reassess your site. That covers more situations than most business owners expect:
- Moving to a new domain name, usually after a rebrand
- Switching platforms, such as WordPress to Shopify or Wix to WordPress
- A redesign that changes your page URLs or site structure
- Merging two websites into one
- Changing hosting providers
- Restructuring your URLs, even on the same platform
The risk level varies. A hosting change with no URL changes is low risk. A rebrand that changes your domain, platform and page structure all at once is the highest risk move a business can make online. If you are planning several of these changes, stage them as separate projects wherever possible so that any traffic drop can be traced to a single cause.
Why Rankings Drop After a Migration
Your current rankings are built on signals Google has collected over years: backlinks pointing to specific URLs, indexed pages, internal links, page authority and content history. None of that transfers automatically. When your URLs change, Google sees a set of brand new pages and has to crawl, assess and score them from scratch.
If the old URLs simply vanish, every backlink you have earned now points at a 404 error. The authority those links carried stops flowing to your site. Google removes the dead pages from its index, and your rankings go with them. A 301 redirect is the mechanism that tells Google a page has permanently moved and passes the accumulated authority to the new address. That is why the redirect map sits at the centre of every serious migration plan.
Even a well-executed migration usually brings a temporary dip while Google recrawls and rescores the site. A clean migration typically stabilises within 8 to 12 weeks. A botched one can take six months or longer to recover, and some sites never fully claw back what they lost.
Step 1: Benchmark Everything Before You Touch Anything
You cannot protect what you have not measured. Before any development work starts, capture a complete picture of your current site:
- Crawl every URL on the site using a tool such as Screaming Frog, and record status codes, canonical tags and existing redirects
- Export your ranking keywords and positions so you have a baseline to compare against
- Pull organic traffic data by page from Google Analytics
- Identify your most valuable pages by traffic, enquiries and backlinks. These are the pages that need the most careful handling
- Export your historical Search Console data. Google only keeps 16 months of it, and once you migrate a domain, the old property stops collecting
- Document your existing page titles, meta descriptions, headings and schema markup
Keep a full backup of the old site. If content, metadata or images go missing after launch, this is your reference copy.
Step 2: Build a One-to-One Redirect Map
This is the single most important piece of work in the entire migration. Every old URL that has traffic, rankings or backlinks needs a 301 redirect to the most relevant page on the new site.
The rules that matter:
- Use 301 (permanent) redirects, never 302 (temporary) ones. Only a 301 passes ranking authority to the new URL
- Map each old page to its closest equivalent, one-to-one. Do not bulk-redirect old pages to the homepage. Google treats that as deleted content and drops the rankings immediately
- Avoid redirect chains. The old URL should point directly to the final new URL, not through two or three hops
- Pages with no traffic, no rankings and no backlinks do not need a redirect. Let them return a proper 404 or 410 so Google's crawl budget goes to pages that matter
- Include image URLs if your images rank in Google Images, which matters for trades, hospitality and retail businesses
Ask to see the redirect map as a spreadsheet before launch. If your developer cannot produce one, that is a warning sign that the migration has not been planned properly.
Step 3: Keep the Staging Site Out of Google
Your new site should be built and tested on a staging environment before it goes live. That staging site must be invisible to search engines. If Google finds and indexes it, your launch-day site gets treated as a duplicate of a site that already exists, and both suffer.
Protect the staging environment with password protection at the server level and a noindex tag across every template. Then, and this is the step almost everyone forgets, confirm those blocks are removed the moment the real site goes live. A leftover noindex tag on a live site will quietly deindex your pages while everything looks fine on the surface. We have seen this single oversight erase a business from search results within a fortnight.
Step 4: Transfer the On-Page SEO, Not Just the Content
When you move platforms, your words might come across, but your SEO settings usually do not. Each of these has to be carried over deliberately:
- Page titles and meta descriptions
- Heading structure, especially your H1S
- Image alt text
- Internal links, updated to point directly at the new URLs rather than relying on redirects
- Canonical tags, checked so each page points to itself on the new domain
- Schema markup, rebuilt if the new platform generates it differently
Resist the urge to rewrite your best-performing pages during the migration. Move them across as they are, let rankings stabilise, then improve them later. Changing URLs, design and content simultaneously makes it impossible to diagnose what caused a drop.
Also, test the speed of the new build before launch. A new site that loads slower than the old one starts life with a ranking handicap, no matter how good it looks.
Step 5: Protect Your Local Search Visibility
This is where most migration checklists fall short, and where Sydney businesses have the most to lose. If you rely on the local map pack for enquiries from customers in Parramatta, Blacktown, Penrith or anywhere else across Greater Sydney, your migration plan needs a local layer:
- Update your Google Business Profile with the new website URL on launch day. This does not happen automatically, and a profile linking to a redirected or dead URL undermines the trust signals your local rankings depend on
- Update your citations. Directories such as Yellow Pages, True Local, Hipages and industry-specific listings all reference your old URL. Work through them, starting with the ones that carry the most authority
- Preserve your suburb and service area pages. These pages often hold your most commercially valuable local rankings. Every one of them needs a direct one-to-one redirect
- Keep your NAP details identical. If the migration coincides with a rebrand, make sure your name, address and phone number stay consistent everywhere they appear, including in your LocalBusiness schema
Losing map pack visibility hurts differently to losing organic rankings. Recovery depends on rebuilding consistency across dozens of external references, which takes longer than fixing anything on your own site. If local rankings are the lifeblood of your business, our local SEO services team can audit your citation footprint before you migrate.
Step 6: Keep Your Visibility in AI Search
Search has changed. Your customers now find businesses through Google's AI Overviews, ChatGPT and Perplexity, and these systems cite specific pages when they answer questions. A migration can quietly remove you from those answers if:
- Pages that AI systems were citing get merged, deleted or heavily rewritten
- FAQ content and question-based headings are stripped out in the redesign
- Structured data disappears when the new platform generates a schema differently
Before you migrate, note which of your pages appear in AI-generated answers for your key services. After launch, check those same queries. Keep your FAQ sections, question-style headings and schema markup intact through the move, because these are the elements answer engines lean on when deciding which sources to cite. Well-structured content that answers a question directly in the first sentence or two travels through a migration far better than content buried in decorative page layouts.
Launch Day: The Checklist
Never launch on a Friday. Go live early in the week, ideally during a quieter trading period, so problems get fixed while your team is at their desks rather than over a weekend. On the day:
- Remove all noindex tags and password protection from the live site
- Spot-test redirects across every page type: homepage, service pages, blog posts, images
- Submit your new XML sitemap in Google Search Console, and keep the old sitemap submitted temporarily so Google processes your redirects faster
- Use the Change of Address tool in Search Console if your domain has changed
- Confirm your analytics and conversion tracking are firing
- Check robots.txt is not blocking anything it should not
- Run a fresh crawl and compare it against your pre-migration benchmark
- Update your Google Business Profile and priority citations
The First 90 Days After Launch
Migration work does not end at go-live. The first three months decide whether you recover fully or watch problems harden into permanent losses. Monitor weekly, at minimum:
- Indexing status of the new URLs in Search Console
- Keyword movements against your pre-migration baseline
- Organic traffic by page, compared with the same pages before launch
- 404 errors and crawl anomalies, fixed as they appear
- Whether your content still appears in AI-generated answers for your core queries
One task worth the effort: contact the websites behind your most valuable backlinks and ask them to update their links to the new URLs. A redirect passes most of the authority, but a direct link passes all of it.
The Mistakes That Cost Businesses Their Rankings
Across the migrations we have repaired, the same failures come up again and again:
- No one owned the SEO. The developer assumed the client had it covered, and the client assumed the developer did
- Redirects were bulk-pointed at the homepage instead of being mapped page by page
- The staging site was left indexable, creating duplicate content before the new site even launched
- A noindex tag survived into production and silently removed the site from Google
- Metadata never made the trip. Hundreds of carefully written page titles were replaced with defaults generated by the new platform
- Local listings were forgotten, leaving the Google Business Profile and citations pointing at dead URLs for months
- The SEO team was called in three days before launch, when the decisions that mattered had already been locked
If a web agency tells you SEO can be sorted after launch, treat that the same way you would treat any of the warning signs in our guide to the red flags of a scam SEO company. The work that protects your rankings happens before the new site exists, not after.
Planning a Migration? Get the SEO Handled Properly
A website migration done well is an opportunity. Faster load times, cleaner structure and better content can leave you ranking stronger than before. Done carelessly, it hands your hard-won visibility to competitors who stayed put.
Digitalzoop manages SEO migrations for businesses across Greater Sydney, from single-location trades and clinics to multi-site operations. We work alongside your web developer from the start, with no lock-in contracts and direct access to the senior team doing the work. If you are weighing up a new website, or you are mid-project and realising SEO has not been part of the conversation, talk to us before launch day. It is far cheaper to protect rankings than to rebuild them.
Not sure whether your current agency is up to the job? Our guide on how to choose a digital marketing agency in Sydney covers the questions worth asking before you commit.
Frequently Asked Questions
How long does it take for SEO to recover after a website migration?
A well-planned migration usually stabilises within 8 to 12 weeks as Google recrawls and rescores the new site. Poorly executed migrations, particularly those with broken or bulk redirects, can take six months or more to recover, and some traffic may never return.
Will I lose SEO if I change my domain name?
Not if the migration is handled correctly. One-to-one 301 redirects, the Change of Address tool in Search Console and updated backlinks preserve most of your authority. Expect some short-term fluctuation while Google processes the change.
Do I need a 301 redirect for every page on my old website?
Every page with traffic, rankings or backlinks needs a one-to-one 301 redirect to its closest equivalent. Pages with no SEO value can be allowed to return a 404 or 410 instead, which keeps Google's attention on the pages that matter.
Does a website redesign affect SEO if the URLs stay the same?
It can. Changes to content, heading structure, internal links, page speed or schema markup all influence rankings even when URLs are untouched. A redesign with stable URLs is lower risk, but the new build should still be checked against the old site before launch.
Should I hire an SEO specialist for a website migration?
If your site brings in meaningful traffic or enquiries, yes. The cost of specialist involvement is a fraction of what a failed migration costs in lost revenue. Bring the SEO partner in before design decisions are locked, not in the final week before launch.