If website traffic drops after a redesign, separate three questions: did fewer people click from search, did the site stop measuring visits correctly, or did visitors stop completing the actions that matter? A redesign can affect all three, and the repair depends on which one changed.
Start with the launch date, the affected landing pages, and the previous versions of those pages. Compare observable behaviour before deciding that Google disliked the design, the new framework caused the loss, or another complete rebuild is necessary.
Timing makes the redesign worth investigating. It does not prove the cause. Search demand, ranking changes, reporting problems, and site defects can overlap.
A real migration question reveals the first trap
In an r/TechSEO discussion after a site transfer and redesign, the poster reported a month without the traffic improvement they expected. An audit tool appeared to label redirects as not followed, and they asked whether they could request that a link be followed.
A reply from u/chaqintaza separated the concepts: a 301 redirect is not an ordinary link with a nofollow attribute. The commenter also asked whether public URLs had actually changed or whether only the hosting provider changed.
The thread does not establish what caused that site's loss. It shows why the vocabulary matters. If a team treats a hosting move, URL migration, redesign, and content rewrite as the same event, it becomes difficult to identify the specific change that needs repair.
Start by naming what actually changed. That is more useful than repeating an audit label you cannot connect to a live response.
Write down the launch changes before opening reports
Create a change log covering the domain, hostname, protocol, URL paths, CMS, page templates, navigation, content, tracking, forms, and hosting. Include changes made shortly before or after the formal launch.
For each item, identify whether it changed everywhere or only on a section of the site. A new blog template may remove supporting text from article pages while service pages remain unaffected. A consent-banner update may change measured sessions across the whole site without changing search clicks.
Keep the previous sitemap, URL list, and page content where available. If no pre-launch crawl exists, use repository history, CMS revisions, stored exports, and authorized analytics records to reconstruct the important pages. Be explicit about what cannot be recovered.
This is not a demand for perfect historical data before acting. It is a way to avoid confusing a known change with an assumption.
Confirm which metric fell
Compare equivalent date windows and keep the same filters. Exclude incomplete recent data and consider weekday patterns. Where the business is seasonal, look at the corresponding prior-year period as additional context.
| Observed pattern | First investigation | What it does not prove |
|---|---|---|
| Search clicks stable; measured sessions fall | Tracking, consent, landing measurement | That rankings collapsed |
| Clicks and impressions fall for moved pages | Redirects, indexing, content, demand | That redirects are definitely the cause |
| Impressions stable; clicks fall | Query mix, position, search appearance | That AI answers caused every lost click |
| Visits stable; inquiries fall | Forms, calls, usability, lead routing | That the site needs more traffic |
| Old-domain clicks fall; new-domain clicks rise | Migration across both properties | That the old-domain decline equals a net loss |
Google's diagnostic guidance considers technical issues, ranking changes, seasonality, reporting anomalies, and URL changes. It recommends inspecting the Search Console performance data rather than treating every drop as the same problem. Google's traffic-drop guide
Search Console clicks and analytics sessions will not match exactly. Use them to investigate divergent patterns, not to demand identical totals from different measurement systems.
Choose the pages that can explain the loss
Sort landing pages by the change in clicks and inspect the largest contributors. A sitewide percentage can hide one previously important page that disappeared, or a template problem affecting an entire category.
Keep old and new URLs mapped together. If a page moved, comparing only the old URL can show a dramatic decline while its replacement receives the traffic. At the same time, do not assume every new-page increase compensates for every old-page loss; compare relevant page groups and queries.
Select a small control group of pages that changed less. If both changed and unchanged sections decline similarly, investigate shared causes and external conditions. If only one new template collapses, prioritize that template.
For each page, record its previous purpose, current purpose, response status, canonical, indexability, content differences, and incoming internal links. This creates a concrete worksheet for the developer and SEO reviewer to work from together.
Test the old URL all the way to its destination
Open an old URL and inspect the complete response path. The question is not simply whether a redirect exists. It is whether it reaches the right replacement, without a loop, an unnecessary chain, or a final error.
For example, an old service page might redirect successfully to the new homepage. The server has technically redirected the request, but the visitor has lost the specific service information they sought. A relevant replacement should preserve the page's purpose where that content still exists.
Google recommends permanent server-side redirects where possible, direct paths to final destinations, and keeping redirects for as long as possible, generally at least a year. Its migration guidance also distinguishes removed content from content that has moved. Google's site-move documentation
Check protocol and hostname variants as well as paths. Test the actual public URLs customers and search engines use, not only the new sitemap. A rule can work for the preferred hostname while another variant still reaches an obsolete server.
Verify the destination is eligible to appear
A correct redirect cannot help much if the destination is unintentionally excluded from search. Inspect the live page's status, robots instructions, canonical, and access requirements.
Common mistakes worth checking include a staging noindex directive carried into production, a canonical that still names the staging host, or a template that points many distinct pages to one unrelated canonical. Also verify that the page does not require a login or fail intermittently.
Use Search Console's URL inspection to compare what Google has indexed with the current live state. The indexed result and a live test answer different questions. A repaired page can be live before Google's stored view reflects the repair.
Do not indiscriminately remove exclusions. Some account pages, filters, and duplicate URLs may be intentionally excluded. Establish the desired state for each affected page type and fix the mismatch.
Compare rendered content, not only screenshots
A redesign can preserve the visual theme while changing the actual information available on a page. Compare headings, explanatory text, tables, links, and other useful content with the previous version.
Check what loads on the initial visit, including mobile behaviour. Content that depends on a failed request, a user interaction, or a broken component may not be reliably available. Inspect the rendered page through appropriate tools rather than assuming that either all JavaScript is invisible or every client-rendered element is harmless.
Also compare meaning. A new service page may look cleaner because the detailed explanation, qualifications, and examples were removed. If those sections answered the queries bringing visitors, restoring their useful substance may matter more than restoring the old appearance.
Keep the task specific: identify what changed, why the lost material was useful, and where it belongs now. Reintroducing every old paragraph without evaluation is not a content strategy.
Bring the launch date and the pages that lost search traffic or inquiries. We can connect the technical changes with page-level evidence and scope the repair.
Check the routes visitors take inside the site
Important pages can become harder to discover when navigation and contextual links change. Compare the links that previously led to affected pages with those that exist now.
A page left in the sitemap but removed from relevant navigation and supporting articles may no longer fit the site as clearly. Restore links where they help visitors complete a task, using descriptive text and the final destination URL.
Check for links that still point through redirects or lead to errors. Also inspect mobile menus and expandable navigation, because a desktop-only check can miss a broken route used by many visitors.
Do not respond by linking every page from every other page. The objective is a coherent path: an overview leads to the right service or detailed answer, and that page leads to a relevant next step.
Test inquiries separately from search recovery
If visitors arrive but inquiries fall, run the actual conversion process. Submit a controlled form, check delivery, confirm the CRM record, and verify that the assigned person receives it. Test telephone links and booking paths on a phone as well as a desktop.
A form can display a successful confirmation while the downstream email or CRM integration fails. Conversely, the lead can arrive correctly while the conversion event stops firing. Those are different defects with different business effects.
Record test submissions clearly so the team does not mistake them for prospects. Compare the number of real inquiries in the destination system with analytics events over the same period, allowing for differences in what each records.
For AI-source reporting specifically, the GA4 AI Assistant troubleshooting guide covers source and channel mismatches. Do not use an attribution discrepancy as proof that a redesign lost all AI traffic.
Use a page-level repair worksheet
Here is an illustrative worksheet for a redesign investigation. These are hypothetical findings, not results from a Pavado customer audit.
| Page group | Evidence | Proposed repair | Verification |
|---|---|---|---|
| Moved service pages | Old paths reach unrelated homepage | Map to equivalent service pages | Check every mapped response and destination |
| Articles on new template | Key explanatory section missing | Restore useful content in template | Compare rendered sample and affected pages |
| All contact forms | Leads arrive; event does not fire | Repair event implementation | Controlled submission plus destination record |
| Account pages | Intentional noindex unchanged | No change required | Confirm intended access and exclusion |
| Seasonal guide | Similar decline last year | Continue demand investigation | Compare queries and seasonal pattern |
Assign an owner and a deployment date to each confirmed repair. State what observation would show the repair worked. “SEO improved” is too vague for a developer to verify; “the old URL reaches the correct indexable replacement” is concrete.
Separate lost visibility from a lower click rate
A simple calculation can prevent an unhelpful diagnosis. In a hypothetical comparison, a page receives 10,000 impressions and 400 clicks before launch, then 10,000 impressions and 250 clicks afterward. Its click-through rate moves from 4% to 2.5%; its impression count has not fallen.
That does not identify the cause. Inspect the queries, positions, devices, and search appearance before deciding whether the title or another factor explains the difference. An unchanged total can conceal a shift toward queries that naturally receive fewer clicks.
Contrast that with a page whose impressions and clicks both halve while its click-through rate stays similar. The investigation should focus first on why fewer impressions occurred. Use the calculation to choose the next check, not as a shortcut to a causal claim.
Decide whether to repair or roll back
A severe verified launch defect may justify a rollback, but assess what the rollback changes. It could restore old content while breaking new forms, losing recent data, or reintroducing another problem.
Where possible, make a targeted repair with a clear expected result. Preserve a record of what changed so later analysis can distinguish the initial launch from the repair. Avoid rewriting titles, changing URLs, replacing templates, and pruning content simultaneously merely because traffic is down.
If the technical checks are sound, broaden the investigation to query demand, competitors, ranking changes, and content usefulness. A clean migration does not guarantee unchanged rankings, and the redesign date may overlap with an unrelated shift.
Monitor recovery without inventing a deadline
Google says processing URL changes can take weeks or longer depending on site size and other conditions. That is guidance about discovery and reprocessing, not a promise that every site will regain its previous traffic by a fixed date.
Track the repaired page groups over comparable windows. Watch whether intended destinations are indexed, relevant impressions return, clicks improve, and real inquiries reach the business. Keep technical verification separate from performance recovery: a redirect can be fixed today while search results take time to reflect it.
The first useful outcome is a defensible explanation of what broke and proof that it was repaired. Build from that evidence. A redesign diagnosis should leave you with fewer unknowns and a working site, not another speculative overhaul.