Traffic drop after a website redesign: an evidence checklist
A report-led sequence for comparing releases, URLs and search evidence after a redesign without assuming that appearance caused the change.
Define the incident before diagnosing the redesign
Folio detail
Write down the release date, the first date on which the change became visible, the affected search type and whether the loss concerns clicks, impressions, enquiries or all three. Compare like with like: the same date range, country, device and query grouping, allowing for weekends and seasonal demand. A redesign may coincide with a migration, revised copy, changed navigation, tracking changes or wider search volatility. Treat those as separate hypotheses. Preserve exports and release notes so later checks rely on dated evidence rather than memory or a single dashboard screenshot.
Reconcile old and new URL inventories
Folio detail
Create a list of important pre-release URLs from the old sitemap, analytics landing pages, Search Console exports or a saved crawl. Match each one to its intended new destination. Test the live status, final URL, redirect hops, canonical target and indexability. A redesign can remove useful pages, redirect several distinct services to the home page, introduce chains, or leave internal links pointing at retired addresses. Record each mismatch by URL and intended correction. Do not infer that a visually similar replacement serves the same search purpose until its content and destination are checked.
Segment the change to discriminate between causes
Folio detail
Group Search Console data by directory, page type, query intent, brand versus non-brand, device and country. A site-wide impressions fall suggests a different investigation from weaker clicks on one template or the disappearance of one service directory. Check whether affected URLs were changed, removed or de-emphasised in navigation. Note external events, manual actions and security notices separately. Segmentation does not prove causation, but it narrows the next test and prevents a broad rewrite when only one release component or page family shows the symptom.
Inspect what search engines can receive and interpret
Folio detail
Check representative templates with URL Inspection and a crawl that renders the page where appropriate. Confirm successful responses, robots access, meta robots directives, canonical signals, titles, main headings and meaningful body text. Look for important content that now depends on interaction, scripts that fail, or mobile layouts that hide essential links. Compare source and rendered output rather than judging only the browser view. Search engines do not require an old-fashioned design, but they do need stable access, understandable content and crawlable routes to the pages that matter.
Repair in dependency order and verify cautiously
Folio detail
Restore availability and indexability first, then correct redirect, canonical and internal-link mismatches before revising page relevance. Use a small, documented change set where the diagnosis remains uncertain. Give every action an owner, affected URLs, rollback note and acceptance check. Request recrawling only for a sensible representative set; it is not a guarantee of indexing. Monitor comparable page and query groups over an appropriate period, while recording other releases. Recovery can be influenced by demand and search-system changes, so report observed movement without claiming that one edit secured a ranking.
Practical incident-folio
Post-redesign evidence folio
Complete one record per release and attach URL-level observations before choosing repairs.
Incident boundaryRelease time, first visible symptom, affected metric, search type, country and device.
Baseline comparisonComparable pre- and post-release periods with seasonality, weekends and reporting changes noted.
URL reconciliationImportant old URL, intended destination, live status, redirect hops and final response.