Skip to content
50% OFF $299 $599
Lock in
§ 2.11.6 ARTICLE
Published VerifiedEvery 6 weeks Sources5 named Authored bySquareRank Team

Migrations · § 2.11.6 · Diagnostic

Squarespace migration traffic drop — what's normal and the four diagnostics that catch the broken ones

A 30 to 50 percent organic traffic drop in the first 60 to 90 days after a Squarespace migration is the normal range2. Anything within that band is a recovery in progress; expect baseline restoration within 90 to 120 days for graceful migrations and 120 to 180 days for migrations with significant URL pattern shifts. Drops above 50 percent — especially drops that show no recovery curve by day 45 — indicate a broken migration that needs intervention, not patience. Four diagnostics distinguish the two scenarios. Run all four within the first 14 days after cutover.

This leaf is the post-cutover diagnostic playbook. The four checks — redirects firing, sitemap submitted, canonicals correct, schema rebuilt — cover roughly 95 percent of broken migrations. If all four pass and the drop is still above 50 percent, the issue is content-side (the rebuild changed substantive content enough that Google is reranking from scratch) and the recovery is longer but still possible.

What's normal — the 30-50% temporary drop range

Days 1 to 14 after cutover show a 10 to 25 percent organic traffic drop as Googlebot starts recrawling. Days 14 to 60 stabilise at 30 to 50 percent below baseline while Search Console catches up and the algorithm rebalances. Days 60 to 120 recover toward baseline, with the steepest recovery happening between days 60 and 90 as the bulk of URLs complete their recrawl-and-rerank cycle. Long-tail URLs continue to recover into days 120 to 180. A drop within this curve is on track.

Moz's migration tracking2 and Ahrefs' migration coverage3 both place the typical dip in the 30 to 50 percent range. Squarespace migrations cluster at the higher end of the range because the operator is simultaneously re-authoring SEO settings, reinstalling schema via Code Injection, and rebuilding pages in a new editor. The work is correct work; it shows up in the analytics as a sharper short-term dip and a steeper long-term recovery.

The normal recovery curve

30-50%

typical organic traffic drop in days 14-60 after a graceful Squarespace migration.

Moz migration guide · 2025
90-120

days to baseline recovery for graceful migrations with complete redirects and schema rebuild.

Moz migration guide · 2025
60%+

drop above 50% by day 45 indicates a broken migration — intervention required, not patience.

Google Search Central · 2026

The four diagnostics that distinguish normal from broken

The four checks: are the redirects actually firing on every legacy URL, is the new sitemap submitted and clean in Search Console, are the canonical tags pointing at the correct URLs, and is the schema layer rebuilt to match what the old site was emitting. Each check takes 5 to 15 minutes; all four together take under an hour and cover roughly 95 percent of broken-migration failure modes. Run all four in sequence; do not skip any.

The fifth, deeper check — whether the rebuild changed substantive content enough that Google is treating the new pages as new content rather than the same content at new URLs — is harder to diagnose and usually only relevant after the first four pass clean. The content-change check is qualitative: read the new versions of the top 20 pages side by side with the old versions and verify the substance matches.

Check 1 — Are the redirects actually firing?

Open Search Console's Coverage report. Look at 'Page with redirect' counts versus 'Not found (404)' counts over the trailing 30 days. A graceful migration shows 'Page with redirect' climbing as Googlebot encounters the URL Mappings, and 'Not found' staying near zero. A broken migration shows 'Not found' climbing too — every spike in 404s is an unmapped legacy URL. The fix is to identify the URLs Search Console reports as 404, add them to URL Mappings, and resubmit.

Cross-reference Search Console's 'Not found' URLs against your Google Analytics top-100 from the pre-migration period. Any URL that drove meaningful traffic before the migration and now appears in 'Not found' is a high-priority redirect. Authoring the missing redirect, saving the URL Mappings panel, and waiting for Googlebot's next recrawl typically restores the URL's ranking within 14 to 30 days.

Check 2 — Is the sitemap submitted and clean?

In Search Console, open Sitemaps. The new Squarespace sitemap (typically /sitemap.xml) should be listed and showing 'Success' with a recent fetch date. If the sitemap is missing, submit it now. If the sitemap is present but showing errors, click into the detail and address each error. Common errors: URLs in the sitemap that 404 (usually pre-launch test URLs Squarespace did not clean up), URLs that are blocked by robots.txt, or URLs that redirect (canonical mismatch).

Squarespace generates the sitemap automatically and updates it as pages are added, removed, or edited. Operators do not edit the sitemap directly. The Search Console submission step is one-time but the recrawl frequency is determined by how often the sitemap reports changes. Force a manual recrawl from Search Console after submitting the sitemap to compress the initial discovery window from days to hours.

Check 3 — Are the canonical tags correct?

Open the live Squarespace site in a private browser. View source on the homepage and on a representative blog post. Search for the canonical link tag and confirm the canonical URL matches the page's own URL. Canonical tags pointing at the wrong URL — most commonly pointing at the pre-launch staging URL because Squarespace did not refresh after the cutover — tell Google the page is a duplicate of a non-existent URL and produce immediate, severe ranking damage.

Google's canonical documentation4 describes the rule: every canonical tag must point at the page's preferred URL, which on a Squarespace site means the page's own production URL. Squarespace handles canonical generation automatically on most pages; the failure mode is when a per-page Code Injection block accidentally overrides the canonical with a hard-coded URL (a frequent mistake in the JSON-LD reinstall step that uses the old URL instead of the new one).

Check 4 — Is the schema layer rebuilt to match the old site?

Run Google's Rich Results Test against the homepage, against three top blog posts, and against any commerce product pages. Confirm: Organization schema fires on the homepage, Article schema fires on every blog post, Product schema fires on every product page, and LocalBusiness or Service schema fires where applicable. Any missing schema reduces Rich Results eligibility and downweights the page's citation candidacy in AI Overviews. The fix is the Code Injection reinstall covered in the JSON-LD leaf.

A WordPress-to-Squarespace migration with Yoast schema loss but no schema rebuild on Squarespace typically shows the recovery curve flattening between day 60 and day 90 because the structured-data layer the old site was using is missing on the new site. The flattening is the symptom; the schema rebuild is the fix. The JSON-LD leaf covers the per-schema-type install pattern.

The 90-day recovery plan

Days 1 to 14: monitor Search Console daily, run all four diagnostics within the first 14 days, patch any issues immediately. Days 14 to 30: shift to weekly Search Console reviews, focus on the URLs that recover slowest, add any missed redirects within 48 hours of detection. Days 30 to 60: ship the install layer enhancements (JSON-LD on the long-tail posts, heading hierarchy patch on collection pages, image SEO cleanup) that compound the recovery. Days 60 to 120: passive monitoring, with the recovery curve flattening into the new baseline.

The single best practice operators skip: the install-layer-as-recovery-accelerator. A migration recovery is not just waiting for Google to recrawl; it is the operator using the recovery window to ship the structural improvements that the old site never had. Article schema on every blog post via JSON-LD Code Injection, the heading hierarchy patch, and the broader site speed work all ship during the 90-day window. By day 120, the new site is structurally better than the old one was; the rankings reflect it.

Keep reading · § 2.11.6