Website Traffic Dropped After a Redesign: What to Check

A traffic decline after a redesign deserves investigation, but the launch date alone does not tell you what failed.

A new design can change URL paths, templates, page content, internal links, redirects, metadata, rendering, analytics, and how search engines crawl, render, and interpret the site. The launch may also coincide with a seasonal demand change, a Google update, a tracking release, or a hosting problem.

The first task is to separate those possibilities. Confirm whether search visibility, visits, conversions, or measurement changed. Then establish what changed, locate the affected pages and queries, and test the parts of the new site that could explain the loss.

This matters especially for an established website. Years of content, URLs, backlinks, templates, reports, locations, documentation, forms, and search visibility may be attached to the old version. The investigation should identify the change that needs to be corrected before anyone decides whether a rollback is necessary.

Confirm what actually declined

A reported traffic drop can describe several different problems. A ranking loss, a Search Console click loss, an Analytics session loss, and a conversion-rate decline are not the same incident. Start by identifying which measurement changed before deciding that the redesign damaged search performance.

Search Console and Analytics measure different stages of the visit. Their totals will not match, and a change in one report does not automatically prove a change in the other.

Check:

• Search Console clicks, impressions, CTR, and position.
• Analytics organic sessions and landing pages.
• Important form submissions, purchases, calls, or other conversion events.
• The date range before and after the redesign.
• Tracking tags, consent behavior, hostname configuration, and channel grouping.
• Search Console properties for the old and new domain, protocol, or subdomain.

Google’s guidance for debugging Search traffic drops recommends checking Search Console data, Google Trends, data anomalies, algorithm updates, indexing, and other possible causes before deciding what changed.

Use the launch date as evidence, not proof

Create a timeline that places the redesign beside every other material change.

Include:

• Design and template releases.
• URL or information-architecture changes.
• CMS, frontend, or hosting changes.
• Domain, DNS, or protocol changes.
• Redirect deployment.
• Analytics and tag-manager releases.
• Content removals or consolidation.
• Robots, sitemap, or indexing changes.
• Search Console and Analytics trend changes.
• Google updates, seasonality, and changes in search demand.

If the decline begins immediately after launch, the redesign deserves close attention. It still does not prove causation. A launch can coincide with an unrelated demand change, a reporting issue, or a search-system change.

The timeline becomes more useful when it is connected to affected URLs and templates. If only a new template lost visibility, inspect that template. If old URLs disappeared across the site, inspect redirects and indexation. If Analytics changed but Search Console did not, inspect measurement before rewriting the website.

Locate the loss before explaining it

Start by finding the shape of the decline before selecting technical fixes.

Compare the affected period with a suitable previous period, then segment the data by:

• Page groups and directories.
• Templates and content types.
• Important landing pages.
• Branded and non-branded queries.
• Query groups and search intent.
• Device and country.
• Web, image, video, or news search where relevant.
• Search appearance.
• New URLs and legacy URLs.

A sitewide decline points toward a different investigation than a loss concentrated in one archive, template, directory, or content type.

Examples:

• A publisher loses clicks across article templates after the new frontend launches. Compare rendered article content, internal links, metadata, structured data, and canonical URLs.
• A law firm’s practice-area pages lose impressions while its homepage remains stable. Compare the old and new page paths, page content, headings, internal links, and local or practice-specific search demand.
• A SaaS company’s product pages retain impressions but lose clicks. Inspect titles, snippets, query mix, search-result features, and whether the redesign made the pages less specific to the searches they previously served.
• A directory loses visibility only for filtered pages. Inspect URL rules, indexation, pagination, faceted navigation, and whether important records are still reachable through crawlable links.

Segmentation should narrow the set of changes that could have caused the loss, not produce a larger report.

This is also where many redesign investigations go wrong. A site can lose impressions without losing its Analytics tracking. It can retain impressions while losing clicks because the query mix or search-result presentation changed. It can retain organic visits while losing leads because forms, calls to action, or event tracking broke. Each pattern points to a different next check.

Check URLs, redirects, and route behavior

URL changes are one of the highest-risk parts of a redesign. A page can look correct at its new address while search engines and external links still point to the old one.

Once paths, page purposes, the CMS, frontend, or route structure change, a redesign may require migration work even when the domain stays the same. Treat the project that way when the address, purpose, or technical delivery of important pages changed.

Build or recover an inventory of:

• Important old URLs.
• New URLs.
• Pages that were removed.
• Pages that were merged.
• Pages whose purpose changed.
• Existing redirect rules.
• Important internal links and backlinks.

For changed URLs, verify:

• The old URL returns the intended permanent redirect where the page moved permanently.
• The redirect points to the closest relevant replacement, not the homepage by default.
• The redirect does not pass through several intermediate URLs.
• The destination returns a successful response.
• The destination is indexable and canonical to itself where appropriate.
• Internal links point directly to the new URL.
• Sitemaps contain the new canonical URLs rather than old or redirected URLs.
• Trailing slashes, casing, query parameters, and localized paths behave consistently.

Google’s redirect documentation distinguishes permanent and temporary redirects and recommends server-side redirects when possible. Its site-migration guidance also recommends URL mapping, updated sitemaps, Search Console monitoring, and checking for incorrect redirects and crawl errors.

A 301 only confirms the redirect type; verify the destination, relevance, status, and canonical behavior as well. A redirect from a specific research report to a generic resources page may be technically valid while removing the page’s usefulness and search relevance.

If rankings fell but the old URLs still resolve correctly, continue beyond the redirect check. Compare the old and new page intent, content depth, internal links, titles, canonicals, and template output. The site can preserve the address while changing what the page means to users and search engines.

Check indexing, canonicals, robots, and sitemaps

Redesigns often carry temporary launch settings into production or generate conflicting signals across the new site.

Check:

• noindex tags on important pages.
• robots.txt rules that block new directories or assets.
• Canonical tags pointing to old, staging, or unexpected URLs.
• Multiple canonical tags on one page.
• Sitemap URLs that redirect, return errors, are noindex, or are not canonical.
• HTTP status codes for pages that should be gone.
• Soft 404 pages that return 200 while displaying a not-found message.
• Preview, staging, or platform subdomains that appear in search systems.
• Search Console URL Inspection for affected pages.
• Sitemap indexation before and after launch.

Google describes redirects, canonical tags, and sitemap inclusion as different canonicalization signals. None guarantees that Google will select a particular URL, so they should agree with the visible content and internal-link structure. See Google’s guidance on canonical URLs.

One easy-to-miss failure is a production page that still contains a staging noindex directive. Another is a sitemap that lists the new pages while canonical tags, internal links, or redirects still point to the old paths. These contradictions make the new site harder to interpret.

Compare content and template parity

A redesign can preserve a page’s general subject while removing the details that made it useful.

Compare old and new versions for:

• Page titles and headings.
• Main copy and supporting sections.
• Product, service, location, report, or course details.
• Internal links.
• Breadcrumbs.
• Related-content modules.
• Author and organization information.
• Structured data.
• Images and captions where they carry context.
• Archive, pagination, search, and filtering behavior.
• Content that is now hidden behind interaction or loaded only after a client-side request.

This is especially important for large websites. The homepage and a few major landing pages may look unchanged while a template change weakens thousands of article, location, directory, or resource pages.

Not every copy change is an SEO error. A new page can be better than the old page. The important question is whether search intent, supporting information, relationships, and internal paths were removed without a deliberate replacement.

Check internal links and information architecture

Redesigns frequently simplify navigation. The result can look cleaner while making important pages harder for users and crawlers to reach.

Inspect:

• Main navigation and footer links.
• Breadcrumbs.
• Category and archive pages.
• Related-content links.
• Links from high-authority pages to important destinations.
• Directory and filtered-navigation paths.
• Orphaned pages.
• Pages that became several clicks deeper.
• Internal links that still point to redirected URLs.
• Links that now require client-side interaction before they exist in the rendered page.

For a publisher, this may mean article archives no longer expose older content. For a professional association, member resources may remain live but lose their public discovery paths. For a multi-location brand, location pages may still exist while the service-area structure that connected them has disappeared.

What matters is whether visitors and search engines can still find the pages the business intends to keep valuable. A cleaner-looking navigation does not answer that question by itself.

Check the frontend and rendering behavior

Modern redesigns often introduce a new frontend layer. That can be a good architectural choice, but it adds more places where content and metadata can diverge between the browser and the HTML delivered to crawlers.

Google explains that JavaScript pages move through crawling, rendering, and indexing. It also recommends using URL Inspection and testing rendered output when JavaScript may affect discoverability. See JavaScript SEO basics and fixing search-related JavaScript problems.

Check:

• Whether important text exists in the rendered HTML.
• Whether titles and canonicals are present before and after rendering.
• Whether dynamic routes return the correct status code.
• Whether missing content becomes a real 404 rather than a visual error state.
• Whether client-side navigation changes the URL and page content correctly.
• Whether JavaScript errors prevent content or links from loading.
• Whether caching serves an old version of the page or metadata.
• Whether the production build behaves differently from preview.

WordPress

Inspect permalinks, theme templates, plugins that generate metadata or redirects, taxonomy and archive behavior, staging settings, caches, and content parity. A theme rebuild can change URL paths or remove structured archive pages even when WordPress remains the CMS.

Next.js or another React frontend

Inspect server-rendered HTML, generateMetadata, dynamic routes, redirects, rewrites, notFound() behavior, client-only content, caching, robots.txt, and sitemap.xml. Next.js documents metadata and Open Graph files, sitemap generation, and the difference between rewrites and redirects.

Next.js can support search, but the production implementation still needs to deliver the right HTML, metadata, routes, and status codes.

Webflow

Inspect page and CMS Collection slugs, 301 rules, canonical settings, sitemap generation, robots configuration, custom code, localization, and the published domain. Webflow documents redirect setup, sitemap configuration, and canonical settings.

Changing a folder, Collection slug, or domain can create a URL change even when the visual redesign appears straightforward. Check the redirect and canonical behavior rather than assuming the hosted platform handled the transition.

Lovable and other AI-assisted builders

An AI-assisted build can produce a useful starting point quickly. It can also leave important launch details dependent on generated routes, project instructions, export decisions, or the chosen hosting path.

Verify:

• Every important route exists in production.
• Each public page has its own title and description.
• Public content is crawlable in the delivered HTML.
• sitemap.xml lists the intended public URLs.
• robots.txt does not block important pages.
• Canonicals use the final custom domain.
• Preview or platform subdomains do not become the preferred URLs.
• Analytics and conversion events work after deployment.
• The team knows where the code, data, environment variables, and deployment configuration live.

Lovable’s own Discoverability guidance describes checks for metadata, sitemaps, robots, structured data, semantic HTML, and canonical tags. Its publishing guidance and GitHub integration documentation also make the deployment path part of the project decision.

AI-assisted builders can support public websites when the production implementation is verified properly. The launch still needs the same route, metadata, indexing, analytics, and domain checks as any other frontend build.

Additional Checks After a Redesign

The main failure points are usually investigated first. The checks below are easy to overlook because the page still loads, the redesign looks correct, or the problem is limited to one template, route, environment, or tracking configuration. Some can still affect a large number of pages.

• A redirect works but points to a broad or irrelevant page.
• A redirect chain adds several hops before reaching the final URL.
• Internal links still point to redirected URLs.
• A sitemap contains redirected, noindex, nonexistent, or non-canonical URLs.
• Canonicals point to a staging domain, old domain, or different URL variant.
• A production page retains a launch-only noindex directive.
• A robots.txt rule blocks a new directory or important rendering resource.
• A missing page returns 200 with a not-found message instead of a real 404.
• Pagination, filters, or archive links disappear from the new templates.
• Breadcrumbs and related-content links are removed during the redesign.
• Structured data no longer matches the visible page.
• A frontend rewrite renders meaningful content only after a client-side request.
• Cache layers serve old metadata, redirects, or page versions.
• Analytics tags or consent configuration change while the page design is rebuilt.
• Form and conversion events stop firing even though page traffic remains stable.
• Search Console data is checked for the wrong hostname, protocol, or property.
• Localized routes lose their alternate links or redirect to the wrong language.
• A Webflow folder or Collection slug changes without a matching redirect.
• A Next.js route, metadata function, rewrite, sitemap, or notFound() path behaves differently in production.
• An AI-assisted build is launched from a preview or exported repository without verifying production routes, metadata, sitemap, robots, analytics, and domain behavior.

Prioritize these checks according to the pattern of the decline. If the data points to one affected template or URL group, start there instead of testing everything indiscriminately.

What to do with the findings

The investigation should end with a decision, not another undifferentiated list of tasks.

Fix the implementation

Choose this path when the platform is still capable of supporting the website and the decline comes from redirects, metadata, content parity, internal links, rendering, analytics, or a contained template problem.

Stabilize and monitor

Use this when the new URLs and content are correct, the evidence shows normal recrawling or reindexing, and there is no specific failure to repair. Monitoring should still cover clicks, impressions, indexing, redirects, important templates, and conversions.

Recover from a redesign failure

A recovery investigation is appropriate when the decline is material, the cause is not obvious from the release record, or several changes happened together. The work should establish what changed before recommending a rollback or another rebuild.

Rebuild or migrate

A broader project may be justified when the redesign exposed structural problems: the content model no longer fits, templates cannot support important page groups, the platform cannot deliver required routes or workflows, or the team cannot maintain the implementation predictably.

A new CMS is justified only when the evidence shows that the current platform or implementation is part of the continuing problem. A traffic decline by itself is not enough.