Introduction: Why Your Rankings Crashed After a Site Migration
If your organic traffic fell off a cliff after launching a new website, you are not alone. Sudden SEO losses after a redesign, platform change, or domain migration hit small and service businesses hard, often at the worst possible moment – right after investing significant time and money into a new site. The frustration is real: the site looks better, loads faster (maybe), and the developer says everything went smoothly. Yet leads have dried up and your phone has stopped ringing.
The actual reason is straightforward, even if the fix is not. When you change urls, templates, or your domain, search engines have to re-learn your entire site. Google does not penalise migrations, but it reacts to broken signals. Every page on your old site carried ranking signals – backlinks, internal links, content relevance, structured data – tied to specific URLs. When those URLs change and the signals break, Google loses the thread. Rankings drop, sometimes overnight. Website migrations can risk search rankings due to these key element changes, and ranking fluctuations are common after site migration, though they can often be reversed with the right work.
Concrete scenarios where this happens include moving from HTTP to HTTPS, switching from WordPress to Shopify, migrating from olddomain.co.uk to newbrand.com, or launching a brand-new design on the same domain with a different url structure. A modest dip of 10–30% in the first two to four weeks can be normal as Google re-crawls and reprocesses. But a significant drop of 30–70% that does not start recovering after a month usually means something is broken and needs fixing. If you are dealing with a traffic loss that is not resolving, Gareth at RedShaw Consulting specialises in technical seo, WordPress, and migration support that helps businesses recover lost traffic and plan safer moves. Getting in touch early through the RedShaw contact page is worth considering before the damage compounds.
1. Confirm the Drop Is Real: Data, Not Just Rank Trackers
Before you panic or blame Google, confirm that traffic and revenue actually dropped – not just a single keyword in one rank-tracking tool. Surface-level alarm (“we lost position 3 for keyword X”) often masks deeper issues or, occasionally, turns out to be tracking noise rather than a genuine problem.
Start with google analytics (GA4). Compare matched time windows: take the 28- or 30-day period before migration launch against the same number of days after. If your new site went live on 3 March 2026, compare 3 February–2 March against 3 March–1 April. Look at organic sessions, goal completions, and revenue. A real traffic drop shows up clearly in these comparisons – for example, organic clicks falling from 2,400 per month in February to 1,000 in March after the new site went live.
Next, use the google search console Performance report. Compare clicks and impressions week-by-week around the migration date. Split queries into branded versus non-branded. A drop in branded search often signals domain change issues or redirect failures. Non-branded drops usually implicate template, content, or canonical problems. Google Search Console can diagnose specific pages that have ranking issues, making it the single most useful tool in this process. Monitoring Google Analytics alongside Search Console gives you the full picture.
Rank trackers can mislead due to personalisation, location, and device differences. Spot-check a handful of core keywords manually in an incognito browser window to validate what your tools are showing. If the data confirms a real drop, move on to diagnosing the cause.
2. Identify the Type and Timing of the Ranking Drop
The shape of the drop – whether it is an overnight cliff, a slow slide, or a folder-level loss – tells you a great deal about what went wrong and where to look first.
Three typical patterns emerge in post migration diagnostics:
- Same-day cliff. Traffic plunges immediately when DNS switches, redirects go live, or new code deploys. This pattern almost always points to redirect failures, noindex leaks, or robots.txt blocks. A drop in traffic after migration can be due to crawlers encountering 404 errors on pages that used to rank.
- Gradual six-to-eight-week erosion. Traffic slides slowly after a big content or layout change. This usually indicates lost internal linking, content thinning, or user engagement regressions that Google picks up over time.
- Folder-level drops. Only certain sections lose visibility – for example, /services/ or /blog/ pages drop while the homepage and about page hold steady. This points to issues specific to those templates, such as a section blocked in robots.txt or a template applying noindex tags.
Pin the exact launch date and time on your analytics and search console graphs. If the site was redeployed on 15 April 2026 at 9pm UK time, mark that point precisely. Group your data by page type – key service pages, location pages, blog posts, product pages – to see which segments contributed most to the drop.
It is also worth checking whether a Google core update landed around the same period. Occasionally a drop coincides with an algorithm change rather than a migration mistake. But in the vast majority of cases, post-migration crashes are caused by on-site technical issues, not algorithms alone.
3. Redirects and URL Mapping: The #1 Reason Rankings Drop
Missing or incorrect 301 redirects are responsible for the majority of dramatic traffic loss after a domain migration, HTTPS move, or url change. The data is stark: redirect failures cause 30–70% traffic loss post-migration, and over 70% of traffic loss cases stem from redirect failures specifically. A single mistake in redirects can wipe out 30–70% of SEO traffic. Skipping 301 redirects can lead to significant ranking drops that take months to reverse.
A 301 redirect is a permanent instruction that tells search engines: “this old url has moved permanently to this new url – transfer the link equity and ranking signals.” 301 redirects transfer about 90–99% of link equity, though they may not transfer 100% of PageRank. Proper 301 redirects help restore traffic after migration by ensuring Google can follow the trail from old urls to new urls.
Creating or auditing a redirect map:
- Export all legacy URLs from the old CMS, a crawler, server logs, or your old sitemap.
- Map each old url to the best-match new url, one-to-one. Properly mapping old urls to new urls is crucial in website migrations.
- For pages with no direct equivalent, redirect to the closest relevant page – not the homepage.
- Audit all 301 redirects to ensure proper mapping. 301 redirects should be audited using a crawler, not manually.
Redirect chains (old-A → old-B → new-C) and redirect loops must be eliminated. Redirect chains can reduce authority transfer significantly, and redirect chains or loops can confuse search engines and hinder crawling efficiency. Every legacy url should resolve directly to a single, live 200-status page.
Avoid mass homepage redirects. Sending 500 old article urls to the homepage instead of relevant categories creates soft 404 issues and indexing problems. Google treats these as signals that the content no longer exists.
Use search console’s Pages report and a crawler like Screaming Frog to find 404s, soft 404s, broken redirects, and urls still returning 200 on the old site. Make sure all protocol and host variants – HTTP versus HTTPS, www versus non-www – 301 redirect to the preferred canonical version. Check for stray 302 or meta refresh redirects that signal temporary moves and prevent full signal transfer. Missing or incorrect redirects can cause significant ranking drops, and identifying broken redirects is a common first step for recovering from migration drops. Verifying redirects and fixing broken links is essential after every website migration.
For a domain migration, use the Change of Address tool in Google Search Console. Keep the old domain live with redirects for at least twelve months. If the original domain is shut down prematurely, backlinks pointing to it become worthless.
Gareth at RedShaw Consulting routinely cleans up messy redirect implementations after DIY migrations and can review server-level rules on Apache, Nginx, Cloudflare, or WordPress plugins. Fixing foundational errors like these can accelerate recovery in search rankings after migration.

4. Indexing, Canonicals and Crawling: Are Your New Pages Even Eligible to Rank?
If Google is not indexing your important pages, no amount of keyword work will bring rankings back. Indexing issues can cause 30–70% traffic loss overnight, making this one of the first areas to investigate after confirming a drop.
Check indexed urls in Search Console. Go to the Pages report and compare the number of indexed urls before and after migration. A sharp drop in indexed pages or a spike in excluded urls is a red flag. Indexing issues can prevent important pages from being ranked, and indexing delays can lead to traffic drops post-migration. Check google search console for indexing status after migration as a matter of urgency.
Common indexing issues after launch include:
- Key templates accidentally marked with noindex meta tags – often copied from the staging environment. Ensuring that noindex tags are removed is vital for indexing the new site.
- Legacy staging rules left in robots.txt that block key areas, such as Disallow: / or Disallow: /services/. Accidentally blocking crawlers in the robots.txt file can lead to site de-indexing.
- Canonical tags pointing to old urls, to category pages instead of the page itself, or conflicting with redirect targets. Self-referencing canonical tags on each page are the safest approach. Wrong canonicals can cancel redirects and confuse Google, effectively making the new page invisible.
Crawled but not indexed pages often explode after migrations. In search console, you will see pages listed as “Crawled – currently not indexed,” meaning Google found the url but chose not to index it. This often ties back to conflicting canonical tags, weak internal links, or thin content on the page.
XML sitemaps matter. The new sitemap should contain only canonical, indexable, 200-status urls on the new site. Updating sitemaps with new urls is important for search engine indexing, and submitting updated sitemaps can help speed up re-indexing after migration. Removing an old sitemap can clear confusion for search engines during the transition. Submit the new sitemap in search console immediately after launch, and consider using the request indexing feature for your most important pages.
If key content or navigation loads only via JavaScript, Google may struggle to see it. Javascript rendering issues are particularly common with custom CMS builds, single-page applications, or headless setups. On new or low-authority sites, this can significantly delay indexing.
A note on core web vitals: big regressions in LCP or CLS from a new design hurt rankings over time. Page performance issues like slow loading speeds can negatively impact rankings. Migrations are a good moment to improve performance, not make it worse.
5. Internal Links, Navigation and Lost Link Equity
Redesigns often change or shrink navigation, sidebars, footer links, and breadcrumbs. This quietly removes internal links that used to support pages driving traffic and leads. Internal linking issues often arise after a website migration, and the impact is frequently underestimated.
Internal links distribute authority across your site and help Google understand which pages matter. Contextual links within articles, menu items, breadcrumb trails, and footer links all contribute. When a redesign strips these away, the affected pages lose the internal link equity that supported their rankings. Internal link equity loss occurs when links are not updated post-migration, and broken internal links can wipe out 30–70% of SEO traffic.
Consider a practical example: your old site had dozens of internal links pointing to /boiler-installation/ from guides, FAQs, and related service pages. The new site launches with a minimal design and only one menu link to that page. Its internal authority is dramatically weaker, and Google notices.
How to audit internal links after migration:
- Crawl the new site and compare internal inlinks per page against crawl data from the old site (if available). Crawling the site after migration can identify all internal links that need updating.
- Identify priority pages whose internal inlinks dropped significantly.
- Internal link audits can help maintain link equity during migrations by revealing exactly where connections were lost.
Practical fixes include adding contextual internal links within service pages and blog posts, restoring breadcrumb trails, and including high-value pages in the main navigation and footer. Broken internal links – those pointing to 404s or redirected urls – should be updated to point directly to final 200-status urls. Broken internal links disrupt user experience and search engine crawling after migration. Updating internal links is crucial during a site migration.
Better internal linking also supports indexation. Pages that are orphaned or weakly linked tend to fall into “Crawled – currently not indexed” status. Internal linking fixes can restore rankings within weeks when the underlying content is solid. Internal link equity loss can occur during migration even on well-planned projects, so this audit should happen early.
Gareth at RedShaw Consulting often combines internal linking improvements with content refreshes during migrations to stabilise rankings and future-proof growth.

6. Content Changes, Templates and On-Page SEO During Redesigns
Even if urls and redirects are perfect, aggressive design changes can still cause rankings to fall when they strip away content, headings, and relevance signals. Changes to content or structured data during migration can affect ranking positions in ways that are not immediately obvious.
Moving from long, detailed service pages to minimal, image-heavy layouts can create what Google considers thin content, even if the pages look better to humans. Thin content after redesign can negatively impact rankings because the page no longer demonstrates the depth and relevance that earned its position. For example, a detailed “How much does roof replacement cost in Manchester?” guide that ranked well as informational content will lose rankings if the redesign turns it into a generic sales pitch. The search intent no longer matches.
Compare a few top-performing urls using the Wayback Machine or old backups against the new versions. Check:
- Word count and depth of information
- Heading structure (H2s, H3s)
- FAQs and supporting detail
- Title tags and meta descriptions
- Image alt text
A migration checklist for preserving on-page SEO should cover title tags, meta descriptions, H1s, structured data, internal links, and body copy that covers the same topics and queries as before.
Watch for duplicate content and keyword cannibalisation that can emerge when a new site splits or merges old pages inconsistently. Consolidate near-duplicates and redirect weaker urls to the strongest version. Structured data – LocalBusiness, Product, Service, FAQPage – frequently breaks with new templates. Test with Google’s Rich Results Test and fix errors quickly, as lost rich snippets depress click-through rates in search results.
Resist the urge to cut helpful text just to declutter. If you need help balancing UX and SEO during a redesign, working with a specialist like Gareth ensures content quality is preserved alongside visual improvements.
7. Staging, Robots and Analytics: Hidden Gotchas That Kill Rankings
Many of the most painful migrations are broken not by complex SEO theory but by simple oversights copied from staging to production. These are often the easiest problems to fix but the most costly when missed.
The classic “staging noindex” issue: developers add noindex meta tags or robots.txt Disallow rules to keep a pre-launch site out of Google, then forget to remove them when the new site goes live. The result is that the whole site or large sections become invisible to search engines. To check, visit yourdomain.com/robots.txt and look for overly broad blocks like Disallow: /. Then inspect meta robots tags on key pages by viewing page source or using a crawler.
Analytics and tracking problems create a different kind of confusion. If GA4 is not installed on new templates, or is only partially implemented, traffic appears to have dropped when in reality it is simply unrecorded. Double-tagging or wrong property filters also distort data. Before concluding that you have a content issue or a technical issue, verify that your tracking is actually working across the entire site.
Verify all main URL variants – HTTP, HTTPS, www, non-www – and both old and new domains in google search console. Confirm ownership for each. This ensures you can see coverage data, exclusion reasons, and indexing status for every variant Google might encounter.
A launch-day checklist worth following:
- Remove staging passwords and access restrictions
- Remove all noindex tags from production templates
- Update robots.txt to allow crawling of all public content
- Submit the new sitemap in Search Console
- Verify GA4 and search console are working
- Run a full crawl of the live site on launch day
Business owners without in-house technical expertise should consider asking a specialist like RedShaw Consulting to perform a post-launch technical audit within the first week. The cost of catching a noindex tag on day two is negligible compared to losing three months of organic traffic.
8. Post-Launch Monitoring: How Long Recovery Takes and What to Watch
Even after fixes are applied, recovery is rarely instant. Google needs time to re-crawl, re-index, and redistribute ranking signals across your new structure. A study of 892 domain migrations found the average time to recover to pre-migration organic traffic levels was 229 days, though well-managed migrations tend to recover much faster.
Most sites recover within two to eight weeks if issues are fixed promptly. A healthy migration timeline typically looks like this:
|
Period |
What to expect |
|---|---|
|
Weeks 1–2 |
Initial dip of 10–30% in traffic and impressions |
|
Weeks 3–4 |
Stabilisation begins; crawl errors decrease |
|
Months 2–3 |
Progress toward or beyond pre migration levels for priority pages |
|
Months 4–6+ |
Long tail keywords and lower-priority pages recover; authority rebuilds |
Track these metrics in google search console: total impressions, total clicks, indexed urls, and coverage errors for key folders like /services/, /products/, and /locations/. In GA4, monitor organic sessions, leads, and revenue. Focus on a short list of priority keywords and priority urls rather than obsessing over every minor fluctuation – tie tracking back to lead and revenue metrics.
Warn your marketing team against over-reacting. Flipping redirects back and forth, undoing the migration, or making large structural changes every week resets Google’s learning process and prolongs slow recovery. Document every major change with dates – for example, “fixed 301 redirects on 10 May 2026” – so you can correlate improvements or further drops accurately.
Monitor core web vitals via search console and PageSpeed Insights during the first 90 days. Performance improvements can be a useful positive signal alongside technical fixes.
If your rankings and traffic have not begun to improve after six to eight weeks of fixing redirects, indexation, and internal links, it is worth getting outside perspective. You can reach Gareth at RedShaw Consulting through the contact page for a structured recovery plan.

9. When to Bring in Expert Help (and What RedShaw Actually Does)
Some post-migration issues can be solved in-house with careful checking and the guidance in this article. But multi-platform migrations, complex WordPress setups, or large traffic losses often justify outside help, particularly when the obvious reason for the drop is not obvious at all.
Situations where professional support from seo consultants is especially valuable include:
- Large domain migrations where the new domain has no existing authority
- Multi-language or multi-location sites with hundreds or thousands of urls
- Significant revenue impact where every week of lost traffic costs real money
- Unclear technical causes even after basic redirect and indexation checks
A technical seo migration audit from someone like Gareth typically includes a full crawl of old and new sites, redirect mapping review, indexation and canonical analysis, and internal linking and content template checks. RedShaw Consulting focuses heavily on WordPress and service business sites but can also support moves between platforms such as WordPress to Shopify or custom builds to WordPress.
The goal is to stabilise and recover lost rankings first, then use the new site structure as a springboard for improved SEO performance – not just a return to the old baseline. Fixing foundational errors can accelerate recovery in search rankings after migration, often turning a few months of pain into a platform for growth.
Bringing an expert in before a migration is usually cheaper and safer than trying to reverse damage months later. If you are planning a redesign, consider reaching out to RedShaw Consulting early to get SEO baked in from the start. There are no fixed packages or guarantees – recommendations are tailored to each site and situation.
Most ranking drops after migration are fixable with systematic work on redirects, indexation, internal links, and content. Businesses do come back stronger when the technical foundations are right, and a new website should be the beginning of better performance, not the cause of lost traffic.
