Replatform your site and keep the organic traffic you already earn

What actually causes traffic to fall after a migration

The story people tell after a bad migration is that the redirects failed. Sometimes that is true. More often the redirects worked perfectly and the traffic still went, because a redirect only preserves the signal pointing at a page. It cannot preserve a page that no longer says anything. If the old service page had eleven hundred words answering nine specific questions and the new one has a hero image and a call to action, the redirect is fine and the ranking is gone.

The second common cause is quieter. A redesign consolidates the navigation, and forty pages that used to be two clicks from the homepage are now four clicks away or only reachable from a sitemap. Internal links carry both crawl access and relevance, and stripping them out changes how the whole site is understood. The third is technical: a staging directive left in place, a robots file copied from the development environment, canonical tags pointing at the old domain, or a rendering approach that serves an empty shell to a crawler.

Rank all of these before you plan mitigation, because effort spent perfecting a redirect map while nobody notices that the new template drops the FAQ content is effort wasted. The order below reflects what usually goes wrong, most damaging first.

• Content loss: pages that existed are gone, or survive with a fraction of the words and none of the specifics
• Missing or wrong redirects: URLs that 404, or redirect to a category page instead of an equivalent page
• Indexation blocks: noindex tags, a disallow rule, or HTTP authentication left on after launch
• Canonical and duplication errors: canonicals pointing at staging or at the old domain, or both www and non www resolving
• Performance regressions: a heavier front end that pushes Core Web Vitals from pass to fail on mobile

Build the URL inventory before anything is designed

You cannot preserve what you have not listed. The inventory is the foundation of the whole exercise and it must be assembled from several sources, because no single source is complete. A crawl only finds what is linked. A sitemap only contains what the CMS chose to include. Analytics only shows pages that received traffic in the window you queried. Old, unlinked, still ranking pages appear in none of the obvious places and are exactly the ones that get lost.

Then enrich each row so that mapping decisions can be made on evidence rather than opinion: clicks and impressions over the last twelve months, entrances, referring domains, indexed status, page type, and the primary query it ranks for. Twelve months matters because seasonal pages look worthless in the wrong quarter.

• A full crawl of the live site, including images, PDFs and paginated series
• Every XML sitemap, including ones the CMS generates but never links
• Search Console pages report and query data, exported for at least the last twelve months
• Analytics landing page data for the same period, so seasonal pages are visible
• A backlink export, so you can see which URLs other sites point at
• Any legacy redirect rules already in place, because you are about to inherit them

How to build a redirect map that holds up

The map is a two column file: old URL, new URL. The work is deciding what goes in the second column. Automated matching by slug similarity is a useful first pass and a poor final answer, because it happily maps a high value guide to a page with a similar name and nothing in common. Automate the easy majority, then review the tail by hand in priority order.

• Use permanent 301 redirects, not temporary ones, unless the change genuinely is temporary
• One hop only. Every additional hop is latency and an opportunity for a rule to break
• Never bulk redirect to the homepage. It is treated as a soft error and it wastes the signal entirely
• Keep the old sitemap live briefly after launch so crawlers rediscover the redirects quickly

1. Normalise both lists: consistent protocol, host, trailing slash and case, with parameters stripped except where they genuinely change the content
2. Match exactly where the path is unchanged. On a redesign this is often most of the site and needs no redirect at all
3. Match automatically on slug and title similarity, then sort the results by confidence score
4. Review every URL with clicks, impressions, referring domains or entrances by hand, and record the reason for each decision
5. For pages being consolidated, redirect to the section of the new page that covers the same topic, and make sure that content genuinely exists there
6. For pages with no equivalent, choose the nearest relevant parent rather than the homepage, and only serve a 410 where the content is genuinely retired
7. Resolve chains by pointing every old URL at its final destination directly, including redirects inherited from previous migrations
8. Test the whole map against staging with an automated crawler, checking status code, hop count and final destination for every row

The pre-launch crawl comparison

This is the single most valuable hour in the entire project and it is routinely skipped. Crawl the live site. Crawl the staging site with authentication handled so the crawler sees everything. Put the two exports side by side and diff them field by field. Every difference is either intentional or a bug, and you want to make that call before launch rather than in the Search Console coverage report three weeks later. Run the diff on the fields below, filtering first to the top few hundred pages by organic value, then scanning the rest for systemic patterns. One page with a shorter title is noise. Four hundred pages sharing an identical title is a template bug.

• Crawl staging in rendered mode if the new site relies on client-side rendering
• Confirm the new site has an XML sitemap listing only canonical, indexable, live URLs

Compare	What you are looking for	Why it matters
Page count by template	New site substantially smaller than old	Content that was quietly dropped in the rebuild
Word count per URL	Pages that lost a third or more of their text	The most common cause of ranking loss after a redesign
Title tags	Rewrites, truncation, duplicated patterns	Titles change click through and relevance immediately
H1 and heading structure	Generic headings, skipped levels, missing H1	Headings carry the topic of the page
Meta descriptions	Missing or auto generated across a template	Affects click through even when rankings hold
Canonical tags	Pointing at staging, the old domain, or self inconsistently	A wrong canonical can deindex a whole section
Indexability directives	noindex, nofollow, robots.txt disallow rules	The classic launch day disaster
Internal link counts	Pages that lost most of their inbound internal links	Buried pages lose crawl access and relevance
Structured data	Schema types present on the old site and missing on the new	Rich results disappear silently
Status codes	New 404s, 302s where 301s belong, redirect chains	Direct signal loss
Rendered versus raw HTML	Content only present after JavaScript executes	Affects crawl reliability and speed
Core Web Vitals on mobile	Regressions in largest contentful paint and layout shift	A heavier rebuild can undo a passing site

The launch sequence, in order

Cutover is a sequence, not a moment. Doing these steps in the wrong order is how sites end up indexed with a staging robots file or with DNS propagating for a day and a half. Schedule launch early in a week, never on a Friday, and make sure the people who can fix things are available for the following forty eight hours.

1. Lower the DNS time to live at least twenty four hours before cutover so the change propagates in minutes rather than hours
2. Freeze content changes on the old site, then take a final crawl and a final export of the URL inventory
3. Deploy the new site with the redirect map loaded and verified in the production configuration
4. Remove staging protections deliberately: authentication, noindex directives and the development robots file
5. Publish the correct robots.txt and the new XML sitemap, and confirm both return a 200 on the live domain
6. Switch DNS or flip the origin, then verify from multiple networks and a mobile connection
7. Run an immediate crawl of the live site, plus a crawl of the old URL list, and confirm every row resolves in one hop
8. Check analytics, tag manager and conversion tracking are firing on the new templates before anyone celebrates
9. Submit the new sitemap in Search Console, and if the domain changed, lodge the change of address
10. Keep the old environment running and reachable for at least thirty days in case a rollback or a lookup is needed

What to monitor in the first thirty days

After launch the temptation is to check rankings hourly and panic at noise. Rankings fluctuate daily under normal conditions, so a single query moving three positions tells you nothing. Watch coverage and errors daily, because they are unambiguous, and watch traffic weekly against the same weekday of previous weeks, because day of week effects are larger than most people assume.

Set the comparison baseline before launch. Record organic sessions, conversions in GA4, indexed page count and the top two hundred queries with their positions in the fortnight beforehand. Without that snapshot you will spend week three arguing about whether things are worse than they were.

When	Check	Act if
Launch day	Crawl of the full old URL list, status codes and hop counts	Any 404, any chain, any redirect to the homepage
Launch day	Analytics and conversion tracking firing on every template	Data is missing or duplicated
Days 1 to 3	Server logs and error reports for crawler activity	Crawlers are hitting errors or being served slow responses
Days 1 to 7	Search Console coverage and page indexing reports daily	Excluded counts climb, or noindex and blocked appear
Week 1	Crawl the new site for internal 404s and orphaned pages	Any high value page has lost its internal links
Week 1	Core Web Vitals field and lab data on mobile	Largest contentful paint or layout shift has regressed
Week 2	Organic sessions and conversions against the pre-launch baseline	Down more than roughly a fifth and still falling
Weeks 2 to 4	Query level positions for the top two hundred terms	Whole clusters have moved, rather than individual queries
Week 4	Indexed page count versus the sitemap count	A material gap that is not closing
Week 4	Referring domains resolving correctly to live pages	Links are landing on errors or chains

A dip is normal. Here is what is not

Be honest with stakeholders before launch, because the conversation is much harder afterwards. Even a well executed migration usually shows some movement for a few weeks while search engines recrawl, reprocess redirects and reassess the new templates. Recrawling a large site is not instant, and rankings can wobble in both directions while that happens. A modest dip that stabilises and recovers over four to eight weeks is a normal pattern, not a failure.

What is not normal is a decline that keeps deepening past the first month, a sudden drop in indexed pages, a whole content cluster disappearing at once, or traffic that plateaus permanently at a materially lower level. Those indicate a structural problem rather than a processing delay, and they need diagnosis rather than patience.

The distinction worth making at the outset is that migration protects the visibility you already have. It does not create new visibility. If a site was underperforming before the move, it will underperform after it, on a nicer template. Improving performance is a separate programme of search work and content, and conflating the two is how teams end up disappointed by a technically successful migration.

What is different about migrating an Australian site

Two things catch Australian sites specifically. The first is geotargeting. A .com.au domain carries an implicit country signal, so if you are moving to a .com or a subfolder you are giving that up and you need to set the target country explicitly in Search Console and make sure hreflang declares en-AU. Sites that move off .com.au without doing this often hold their global rankings and quietly lose the Australian ones, which is the only market that pays them.

The second is timing. Australian buying seasons are not the northern ones. Migrating a retail site in October puts your riskiest fortnight straight into the run up to Black Friday and Christmas, and migrating a services site in late December means the dip lands when nobody is at their desk to notice it. February and the middle of the year are far kinder. If you are in a sector with a hard cycle, such as an RTO around enrolment periods or an construction business around end of financial year claims, plan around it rather than through it.

A smaller one worth knowing: if your hosting is moving offshore as part of the migration, Australian visitors will feel the added latency and your Core Web Vitals will be measured on that experience, because field data comes from real users. A site that scored well on a Sydney server can slip below the threshold on a US one without a single line of code changing. Where the site handles personal information, moving hosting across a border also engages Australian Privacy Principle 8, so it is a legal question as well as a performance one.

• Set the geographic target in Search Console the day the new site goes live if you are leaving .com.au.
• Declare hreflang en-AU and x-default on every page, pointing at the canonical URL.
• Avoid migrating a retail site between mid October and early January.
• Check where the new hosting physically sits, and test Core Web Vitals from an Australian connection rather than a default US test location.
• If the old site had a Google Business Profile linked to specific landing pages, update those links or the local pack loses its destination.

If traffic has already dropped, work in this order

Post migration recovery is a diagnostic exercise, and the order matters because the cheap checks eliminate the most common causes in under an hour. Resist the urge to start rewriting content on day two. Verify that the site can be crawled and indexed first, then that the redirects resolve, then look at what changed on the pages themselves.

1. Confirm the site is indexable: check robots.txt, meta robots, HTTP headers and any authentication left in place
2. Check canonicals resolve to live, self referencing URLs on the correct domain and protocol
3. Recrawl the complete old URL list and fix anything returning a 404, a chain or a soft error
4. Compare Search Console query data before and after, and identify which page clusters lost impressions rather than which queries lost positions
5. For each affected cluster, diff the old page against the new one on word count, headings, internal links and structured data, using a cached or archived copy if needed
6. Restore the substantive content and the internal links that were removed, rather than adding new content around the gap
7. Resubmit the sitemap, request indexing for the highest value URLs, and then allow several weeks before judging the result