Website redesign without losing Google visibility

Last updated: 2026-09-16

The risk depends above all on the real scope of the project. Changing just the visual layer is a different situation from changing URLs, content, navigation, the domain or technology at the same time. The more of these elements change at once, the broader the control the rollout requires.

The goal should be to limit risk and detect problems quickly, not to promise identical rankings after publication. Google doesn't guarantee a specific recrawl time or rankings after changes.^[1][6]

A visual redesign vs migrating URLs, content and technology

If the URLs and content stay unchanged, the scope of migration work may be smaller. When a subpage's URL changes, you need to decide where the old URL should lead. A change of content, in turn, requires assessing its existing function: it's not just about the length of the text, but about what needs and queries the page responded to.

Before work starts, you should therefore write down whether the project includes changing the domain, URL paths, the menu, the CMS, content templates or indexing rules. This list defines the scope of the inventory and testing.

The basis of a migration is a list of the current URLs, with a decision for each important one. Before removing a URL, you should check its traffic, impressions, links and role in the architecture. If it still has value, it should be linked with an equivalent or get an appropriate redirect. However, the effect depends on the content, the accumulated signals and the quality of the implementation, so this doesn't guarantee that rankings will be preserved.^[1][9][10]

The question of how to order a website should also include giving the contractor information about URLs that must not be accidentally removed. The scope document can also serve as a basis when a website quote is being prepared, but migration decisions still require a separate inventory.

How to choose priority URLs

In the working table, for each old URL you should record at least its planned status and the new URL or the reason for removal. Pages with traffic, impressions, links or an important role in navigation require priority assessment. A URL map is therefore a map of decisions about content and architecture, not just a technical list of redirects.

When to use a redirect and when to remove a page

If an existing URL changes to a different one, you should prepare a permanent 301 or 308 redirect to the closest possible equivalent.^[1] You shouldn't automatically redirect all removed URLs to the home page. First you need to find a topically matching target, and handle the lack of an equivalent in line with the purpose of the given URL. The right decision depends on the type of page and the availability of current content.^[9][10]

The new version has to be tested before publication, and the most important checks repeated on the production domain. The test should cover the URLs, links, availability, redirects, indexing rules, canonicals and the sitemap.^[1]

Staging: noindex, robots.txt and access for Googlebot

noindex is a directive indicating that a page shouldn't be indexed. For Googlebot to read it, it has to have access to the page. So you shouldn't also block its crawling via robots.txt if the method of exclusion is meant to be noindex.^[2]

Before launching production, you need to make sure the pages meant for it haven't kept temporary blocks from the test environment.

What to verify after production launch

After the cutover, canonicals, redirects and the sitemap should point to a consistent version of the target URLs. A canonical is a signal indicating the preferred URL among similar versions, but Google may choose a different URL. The actual choice therefore has to be verified in Search Console.^[3][4]

An up-to-date sitemap helps Google discover new and changed URLs, but it doesn't guarantee their indexing or immediate crawling.^[5][6]

The assessment of a migration shouldn't rely solely on manually checking a few rankings. In Google Search Console, you should compare clicks, impressions, CTR and queries for the most important pages.^[7][8] The report shows the change in results, but on its own it doesn't indicate the cause.

What data to compare in Google Search Console

The reference point should be the period before publication. Analysis at the level of pages and queries lets you establish which areas the change concerns. Then you can move from data for the whole website to checking specific URLs.

A change in clicks or impressions for an important page

Compare the queries related to this URL, and then check its current state.

The problems concern individual URLs

Verify their availability, redirects and the URL chosen by Google as canonical.

The new URLs aren't visible

Check whether they're in the current sitemap and whether they can be fetched.

The change affects a larger set of pages

Go back to the URL map and check whether a shared element of the rollout needs correcting.

From data to diagnosing a specific URL

A change in the performance report is the beginning of a diagnosis, not its result. For the most important URLs, you need to compare the visibility data with the indexing status, the redirect, the canonical and the scope of content changes. This order limits hasty fixes in areas the problem doesn't concern.

A well-planned migration limits the risk and makes it easier to detect errors, but it doesn't ensure identical rankings or a specific recrawl time.^[1][6] For this reason, the success criterion should include a controlled rollout, preserving important URLs and the ability to diagnose quickly.

Not every drop in clicks means a technical error. Search Console data has to be interpreted in the context of specific URLs, queries, indexing and content changes. Without this, the report alone doesn't make it possible to identify the cause.^[8]

Sponsored article