Traffic Dropped After a Website Redesign or Migration: How to Diagnose and Recover

The new site looks better, loads on every phone, and the client loves it. Then, a week or two after launch, the analytics graph slopes down, inquiries dry up, and someone asks why the old site got more leads. Organic traffic has dropped after the redesign, the move to a new host, the switch to a page builder, or the domain change.

Under the hood, Google is re-learning your site. Every URL that changed, every page that disappeared, and every signal that moved (titles, headings, internal links, canonicals) has to be recrawled and reassessed. A well-handled launch causes a small, short wobble. A launch with a mechanical mistake, such as a staging noindex or missing redirects, causes a deep drop that does not recover by itself. This guide is for designers, agencies and owners who need to find out which situation they are in and fix it, in priority order.

What is happening

A traffic drop after launch has three possible sources, and they need very different responses:

Source	How it shows	Response
Measurement broke	Analytics down, Search Console clicks steady	Fix the tag or consent setup; no SEO problem exists
Mechanical SEO fault	Search Console clicks fall sharply soon after launch; pages leave the index or 404	Fix the fault urgently (noindex, robots.txt, redirects, canonicals)
Content and relevance changes	Gradual decline on specific queries; pages still indexed but rank lower	Restore lost content, headings, internal links and page speed

Google treats each URL as its own document. When /services/roof-repair/ becomes /roof-repair-services/, the old URL’s history only carries over if a 301 redirect connects them. When a long, detailed page becomes a short, image-heavy one, the new page may no longer be the best answer for the queries the old one won. Neither change is visible in a design review, which is why they slip through.

Before you start

• Access you need: Search Console (ideally a Domain property covering both old and new hostnames), your analytics account, the WordPress dashboard, and SSH or SFTP. For a domain change you need Search Console access to both domains.
• Old site evidence: a copy of the old site, its sitemap, or a crawl export. If you have none, the Wayback Machine at web.archive.org and the Search Console Pages tab for dates before launch can reconstruct the old URL list.
• Backup: back up the database and files before bulk changes to redirects, settings or content.
• How to run commands: curl runs on your computer (built into macOS and Linux; on Windows use curl.exe in PowerShell, or WSL). wp commands run in an SSH terminal in the folder containing wp-config.php; some hosts call it wp-cli.

Step 1: Separate broken tracking from real traffic loss

Search Console counts clicks from Google’s side, so it does not depend on your analytics tag. Open Performance, Search results, choose Compare in the date filter, and compare the four weeks after launch with the four weeks before (or the same period last year if the business is seasonal). If Search Console clicks are steady while analytics shows a collapse, your traffic is fine and your measurement is broken.

Common tracking failures after a rebuild

• The tag never made it across. The old theme had the Google tag in its header file; the new theme or builder template does not.
• Consent changes. A new cookie banner, or Consent Mode configured differently, means visitors who decline are no longer measured the same way. Reported traffic can fall while real visits do not.
• Wrong property or duplicate tags. The new site sends data to a staging property, or loads the tag twice, which distorts engagement figures.
• A speed plugin delays or breaks the tag. Script delay features can stop analytics from firing until interaction (see FG-47).

Check the tag in the live HTML:

curl -s https://example.com/ | grep -o -E 'G-[A-Z0-9]{6,}|GTM-[A-Z0-9]+' | sort -u

Run this on your computer. Replace example.com with your domain. -E enables the pattern that matches Google tag IDs (starting G-) and Tag Manager containers (starting GTM-); sort -u removes repeats. Good output is exactly the ID or IDs you expect. Empty output means the tag is missing from the HTML, or added later by a consent tool or script delay, which you then confirm in the browser’s devtools Network tab by filtering for collect. A different ID than your analytics property means data is going elsewhere.

Step 2: Find exactly what lost traffic

In the Performance comparison, open the Pages tab and sort by the click difference. Then open the Queries tab and do the same. You are looking for patterns:

• Old URLs losing clicks, new URLs not gaining them: redirects are missing or wrong.
• The same URLs losing clicks: those pages changed in content, titles, internal links or speed, or were dropped from the index.
• Everything falling at once on one day: a site-wide fault such as noindex or robots.txt (see FG-77).
• Brand queries steady, non-brand queries down: relevance and content changes, not a technical block.

Click a losing page, then switch to the Queries tab: Search Console filters queries to that page, so you see exactly which searches it stopped winning. Export both tabs; they become your work list.

Step 3: Check for leftovers from staging

These are the most damaging mistakes and the quickest to fix, so check them before anything subtle.

Noindex left on

wp option get blog_public
curl -sI https://example.com/ | grep -i 'x-robots-tag'
curl -s https://example.com/ | grep -io '<meta[^>]*robots[^>]*>'

Run the first over SSH in the site folder and the others on your computer. blog_public should be 1; 0 means Settings, Reading still discourages search engines. The header check should print nothing or a line without noindex. The meta check should print nothing or a tag without noindex. Any noindex on a live page you want ranked is your first fix. Also check your SEO plugin’s per-type settings, which a staging export can carry over.

Staging robots.txt

Open https://example.com/robots.txt. A Disallow: / under User-agent: * blocks the whole site. If a physical robots.txt file was uploaded from staging, it overrides WordPress’s virtual one. FG-80 covers this in detail.

Canonicals pointing at staging

curl -s https://example.com/IMPORTANT_PAGE/ | grep -io '<link[^>]*canonical[^>]*>'
wp db search 'STAGING_HOSTNAME' --all-tables --stats

Run the first on your computer and the second over SSH in the site folder. Replace IMPORTANT_PAGE with the path of a page that lost traffic and STAGING_HOSTNAME with the staging domain, for example staging.example.com. The canonical should be the live URL of that exact page. wp db search looks for the string in every table, and --stats prints a match count per table. Good output is zero matches. Matches in an SEO plugin’s tables, wp_options or builder data mean settings or content still point at staging; fix them with a careful wp search-replace after a backup, using --dry-run first (FG-40 covers search-replace for migrations).

Step 4: Check redirects for every old URL

If URLs changed, every old URL that had traffic or links needs a single 301 to its closest new equivalent. Redirecting everything to the homepage does not preserve relevance and Google may treat such redirects as soft 404s. Building the full redirect map is covered in FG-38; here you verify it.

while read -r url; do
  printf '%s  ' "$url"
  curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' "$url"
done < OLD_URLS.txt

Run this on your computer in macOS, Linux or WSL. Replace OLD_URLS.txt with a text file of old URLs, one per line, taken from your pre-launch Search Console export or the old sitemap. -o /dev/null discards the page body, and -w prints the status code and the redirect target. Good output is 301 followed by the matching new page. Bad output is 404 (no redirect), 302 (temporary, which signals the move may not be permanent), 200 on an old URL that should have moved, or 301 to the homepage for pages that had a real equivalent. If a target itself redirects, you have a chain; FG-41 covers those.

Step 5: Look for removed content and weaker pages

Designers often cut text to make pages cleaner. That text may have been what ranked. For each page on your losing list, compare old and new versions side by side (the Wayback Machine helps):

• Is the main heading and title still about the same topic and wording people search for?
• Are the sections that answered specific questions still there, or moved into tabs, sliders and accordions that load only on click?
• Did whole pages disappear, such as an FAQ, a location page, or a blog archive, without a replacement?
• Did images lose their alt text and file names during the rebuild?

Restore the useful content in the new design. Fixing a design is easier than rebuilding lost relevance later.

Internal links

New menus are often smaller, and old footer links, related posts and in-text links vanish. Pages that lost internal links lose importance in Google’s eyes. Check whether body content still links to the old URLs, which now redirect:

wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_status='publish' AND post_content LIKE '%OLD_PATH%'"

Run this over SSH in the site folder. Replace OLD_PATH with an old URL path, for example /services/roof-repair/. $(wp db prefix) fills in your table prefix automatically. Good output lists no rows. Rows mean those posts still link to the old address and should be updated to the new URL. Builder content stored in post meta needs searching there as well.

Step 6: Check speed and rendering

Slower pages

Heavier themes, sliders, video backgrounds and builder markup can slow pages a lot. Speed alone rarely explains a big drop, but it matters for users and for crawl capacity on large sites. Compare old and new Core Web Vitals in Search Console under Experience, and use PageSpeed Insights on the losing pages. FG-11 covers design-driven slowness.

Content that only appears after JavaScript runs

Google does render JavaScript, but content that appears only after clicks, scrolling or late script loading may not be seen, and rendering can be delayed. Open URL Inspection, run Test live URL, then View tested page and look at the HTML tab: search it for a sentence from the page. If it is missing, Google is not getting that text. Also compare with the raw HTML:

curl -s https://example.com/IMPORTANT_PAGE/ | grep -c 'A SENTENCE FROM THE PAGE'

Run this on your computer. Replace IMPORTANT_PAGE and the sentence with real values from the page. -c counts matching lines. A count of 1 or more means the text is in the server HTML, which is the safest state. Zero means it is injected by JavaScript; check that the rendered HTML in URL Inspection contains it, and prefer server-rendered content for anything important.

Step 7: Check international and domain-level signals

If you run language or country versions, check that hreflang annotations survived the rebuild, point at the new URLs, and are reciprocal (each version lists the others and itself). Broken hreflang can send visitors to the wrong language version rather than removing traffic entirely, so look at traffic by country in Search Console.

For a domain change, confirm both domains are verified, the old domain 301s every URL to the matching new URL, and you have submitted the move using the Change of Address tool in the old property’s settings. Keep the old domain registered and redirecting for the long term.

Advanced: a prioritized recovery checklist

Work top to bottom. Each item is ordered by how much damage it causes and how fast it can be fixed.

1. Indexing blocks: no noindex on live pages, robots.txt allows crawling, no X-Robots-Tag on live.
2. Canonicals: every page’s canonical is its own live URL, never staging or the homepage.
3. Redirects: every old URL with clicks or links returns one 301 to its true equivalent.
4. Status codes: real pages return 200, removed pages 404 or 410, no soft 404s.
5. Sitemap: the new sitemap lists only live canonical URLs and is submitted in Search Console. Temporarily keeping a sitemap of old URLs can help Google discover the redirects faster; remove it once they are processed.
6. Tracking: the analytics tag fires on every template and consent settings are understood.
7. Content parity: titles, headings and key sections restored on pages that lost traffic.
8. Internal links: menus and body links point directly to new URLs.
9. Rendering and speed: important text is in the HTML, pages pass Core Web Vitals where possible.
10. Hreflang and structured data: annotations and schema survived the rebuild.

After fixing, request indexing for your most important pages, watch the Page indexing report (FG-78 explains each status), and compare clicks week over week. Realistically, fixes to mechanical faults show effects as Google recrawls, often within days for major pages and longer for the rest. Content and relevance losses take longer and are not guaranteed to return to previous levels.

To spot faults automatically, crawl the live site with a desktop crawler such as Screaming Frog SEO Spider or Sitebulb and filter for non-200 status codes, noindex pages, canonicals pointing to another host, and pages with few inbound internal links.

When to contact your host

Open a ticket if you find an X-Robots-Tag header or robots.txt you did not create, if old URLs return server errors instead of redirects, if the server is much slower than before the move, or if the migration left the old site live on another address. Include:

• The launch or migration date and the date the drop began, in UTC.
• Example old and new URLs with the full curl -sI output for each.
• Any CDN request or ray IDs from the response headers.
• What was moved: domain, server, PHP version, CDN, caching layer.
• Screenshots of Search Console Performance comparisons and Page indexing reasons.

Our diagnostic tools can check redirects, status codes and headers for old and new URLs. If the new site is actually down or erroring, go to the Emergency Room first.