Why a redesign changes search behaviour

A new website can look substantially better and still lose pages that have produced leads for years. Modern design itself is rarely the cause. Development changes URLs, headings, copy, navigation, internal links, response speed, or the way content is delivered. To a search system, this is not merely the same site in new clothes; it is a new set of signals, some of which may contradict the old set.

Google’s current site-move documentation explicitly says that significant changes may cause temporary ranking fluctuation while URLs are recrawled and reindexed. A promise of “not one day of decline” is therefore not testable in advance. The testable work is preserving valuable correspondence, reducing simultaneous changes, and detecting errors quickly.

For a decision-maker, an SEO-safe redesign begins before the first visual mock-up. The team needs to know which pages are already found, for which queries, where visitors enter, what they do next, and which external sites link to those pages. Without that map, designers and developers unknowingly make business decisions based on appearance.

Record what already works first

Export all known URLs from the content system, sitemap, analytics, Google Search Console, and Yandex Webmaster. Preserve separate lists of pages with organic visits, leads, sales, and external links. The lists will differ: a page may be absent from navigation and still receive visits from search or an old publication.

For each page, record its purpose, primary query, heading, important content, business action, and future location. Keeping the URL is safest when the section remains. When a URL genuinely changes, the old page should lead to the closest new equivalent rather than the homepage. With no equivalent, a genuine 404 or 410 may be clearer to both search system and person than an irrelevant redirect.

Compare content by how it answers the query, not by word count. A new screen can be shorter and better if it preserves prices, conditions, specifications, and the next step. Removing a size table, delivery regions, or a named service changes the page’s meaning even when the general marketing copy has become more elegant.

The URL map must precede redirect code

Google recommends mapping old to new URLs, using server-side permanent redirects, and avoiding the mass redirection of unrelated pages to the homepage. Its redirect documentation describes a permanent redirect as a signal that the destination should become canonical.

The Yandex guidance for structure and design changes has the same practical frame: a server-side 301 for a changed location, a crawlable new page returning 200, an updated sitemap, and new navigation links. When design changes without URL changes, Yandex still tells owners to ensure that the crawler receives the page content, including on JavaScript sites.

The mapping table becomes a shared contract for SEO specialist, editor, and developer. It should distinguish exact move, consolidation, removal, and unresolved case. An automatic rule based on similar URL words is convenient, but cannot know that two similarly named pages satisfy different buyer needs.

Test the staging site as a crawler and as a customer

Checking a handful of pages creates false confidence. Use an automated crawl over the complete inventory and manually read the most valuable templates on desktop and mobile. Categories, product pages, articles, regional landing pages, and empty states fail in different ways.

When domain, CMS, structure, and design all change together, a failure is harder to isolate. Google recommends sequencing major changes where possible. Even if a business deadline requires one public switch, the team can separately accept data, URLs, server output, interface, and analytics before traffic moves.

  1. Every future URL returns the expected status, one primary heading, and content in initial HTML or through the agreed crawlable delivery method.
  2. Canonical and alternate links point to the correct new versions, and staging noindex rules have not moved into production.
  3. Robots rules open the intended sections, while the sitemap contains only canonical, available URLs—not redirects or errors.
  4. Every old URL in the map makes one server-side hop to a specific new page, without chains or loops.
  5. Navigation, breadcrumbs, related reading, images, and documents use new URLs instead of silently relying on redirects.
  6. Forms, phone interactions, commerce, and analytics preserve the business actions used to compare the old and new site.

The old site remains part of the operation after launch

For a domain change, Yandex tells owners to verify both locations, check the new one, enable redirects, and submit a move request. Google likewise asks teams to monitor old and new URLs and retain redirects for a long time; its current guide gives at least one year as a general benchmark. Removing the old domain and configuration immediately after release is risky.

During the first days, do not watch aggregate traffic alone. Compare important pages and query groups, 404 and 500 responses, new-URL indexing, crawler activity, speed, and business actions. A large deviation in one template is more useful than “traffic fell ten per cent”: it has an investigable cause and an owner.

A project estimate should therefore show separate work for inventory, URL mapping, technical SEO, automated checks, and post-launch observation. This is not insurance against every search-algorithm change, nor a guarantee of a flat graph. It prevents the business from losing earned demand to an unmatched address, crawler-hidden text, or a redirect nobody tested before launch night.