Should I Change Page URLs During a Website Redesign?

What is this review for?

A URL is a page's address. During a redesign, a team may reorganize services, combine articles or move to a different website platform. Those decisions can change addresses even when the business itself has not changed. The owner does not need to write redirect rules, but should understand which destinations are being kept, replaced or retired.

This is the destination review within our website redesign and AI visibility guide. It addresses changed addresses, rather than launch restrictions or the wording inside a page.

Evidence: c-move

What should a destination review tell you?

Google's site-move guidance calls for mapping existing URLs to their new destinations and monitoring the move. It warns against sending many unrelated old pages to an irrelevant destination such as the homepage. Google site-move guidance.

Our recommendation is to ask for an explanation in customer terms alongside the technical map. If a customer followed an old article link, what useful answer will they reach now? If a service has been retired, what is the honest outcome for that request?

Do not assume every old page deserves a replacement. The important distinction is between an intentional retirement and an accidental loss. The business should know which is which before it approves the map.

Evidence: c-move

Which changes deserve a closer look?

Same answer, new address

Confirm that the replacement still serves the original question.

Several pages merged

Check whether the combined page preserves the useful distinctions.

Service discontinued

Decide what customers should learn about its unavailability.

Article removed

Record why it is no longer useful and whether a suitable replacement exists.

Evidence: c-move

Consider a hypothetical home-service company that combines repair and installation pages. A customer looking for emergency repair should not have to infer whether the new installation overview covers repairs at all. The destination may exist and still be a poor answer to the original request.

This example is a review scenario, not a measured traffic loss or an AE client migration. Ask the business reviewer to accept a relevant repair destination or revise the proposed merger before the technical owner implements it.

Evidence: c-move

What does a useful review record include?

Keep the destination map connected to a business reviewer who can settle questions about service meaning. Technical staff should not have to guess whether two services are interchangeable.

Pay special attention to links already used in printed materials, customer emails or partner listings. These are customer touchpoints even if you do not have a traffic report for them. Ask who owns updates to those materials and whether the transition leaves any confusing promises in circulation.

A shortened URL can be reasonable. So can keeping an existing address that customers already use. The useful decision is whether the proposed change improves the site enough to justify the work and review it creates.

A useful acceptance note is specific: “The old repair page now leads to the current repair service, and the business has confirmed the service description.” If the old address leads somewhere unexpected, assign that routing issue to the technical owner. If the destination is correct but the service has changed, the business needs to resolve the wording. These are proposed review records, not examples of completed work.

Evidence: c-move

What if the team says all redirects are done?

Ask what the statement covers. Does it refer to the whole known inventory or a sample? Which exceptions remain? Does the evidence show the destination reached, or only that a rule was entered somewhere?

Our recommendation is to ask the team to demonstrate representative journeys from the original address to the intended answer. Review the answer as well as the route. A working redirect is not proof that the right service description survived.

For that second question, use the content-loss review. For deciding what the launch evidence proves, use the post-launch review.

Evidence: c-move

How would you review a destination map in practice?

Imagine a home-service company redesigning a site that explains repairs, installations and maintenance. The business has decided to keep repairs separate from installations, combine overlapping maintenance explanations, and retire a service it no longer offers. This is a hypothetical review exercise. It provides no evidence of a completed migration, customer outcome or traffic change.

Our recommendation is to begin with the original customer question for each page. A repair page may answer whether the business handles a particular problem. An installation page may explain what a new project includes. Even if both pages lead to the same inquiry team, they do not necessarily provide the same answer. The owner should approve that meaning before the developer implements destinations.

For each row, ask the team to identify the proposed treatment: keep, move, merge or retire. Then ask what the visitor will find. “Move” should name an intended replacement; “merge” should identify where each useful distinction goes. “Retire” should state the business reason and whether a relevant replacement exists. The category alone is not an acceptance decision.

Google's mapping and redirect guidance supports reviewing the relationship between old and new destinations. The customer-question notes described here are our recommended business layer on that technical work, not a format Google requires. Complete the exercise by accepting the meaning of each proposed destination or returning a specific row for correction.

Evidence: c-move

When does keeping an address make sense?

If the customer question and page purpose remain the same, ask what benefit a new address provides. The redesign may improve layout, navigation and wording without needing a new URL for every page. The owner can request a reason for each class of address changes instead of reviewing a long list as though all changes were inevitable.

A useful decision note could say that the service answer stays at its existing address while its layout changes. That note still needs review of the delivered page. Keeping an address does not prove the content survived, the page remains accessible or the contact journey works. It simply resolves the destination decision for that row.

Where a platform change makes some address changes necessary, ask the developer to explain the affected pattern in plain language. Identify any exceptions that do not follow the pattern. The business does not need to choose implementation syntax; it does need to understand whether an important service or educational answer falls outside the expected mapping.

Avoid treating a cleaner-looking URL as a complete business case. It may be a reasonable editorial preference, but accepting it also means accepting the associated mapping and follow-up work. Record the reason, the intended destination and the person who will check the result. That creates a testable decision instead of a general instruction to tidy the site.

Evidence: c-move

How should you evaluate a move, merger or retirement?

For a move, compare the old question with the replacement answer. If the old page explained repair availability and the new page explains only installations, the owner has a meaning problem even if the route functions. Ask for a relevant destination or a revised page that accurately covers the intended service. Do not use a broad page merely because it is easy to select.

For a merger, identify the distinct answers before approving the combined version. A maintenance overview might legitimately absorb repeated introductory material while retaining separate explanations of inspection, scheduling and exclusions. Those details should reflect the actual business. If the owner cannot confirm them, the next action is factual review, not a stronger redirect claim.

For retirement, ask whether the offering or information has become obsolete. If no relevant replacement exists, record that fact for the technical owner. Google's guidance warns against redirecting many unrelated URLs to an irrelevant destination such as the homepage. It does not mean the business must invent a replacement service just to avoid an empty row in its inventory.

Keep the decision explicit enough that another supplier could understand it. “Retire because this service is no longer offered; no equivalent replacement accepted” is different from “send everything to services.” The developer can recommend the appropriate implementation for the accepted business decision. The owner then reviews whether the resulting visitor experience honestly represents the current offering.

Evidence: c-move

What about printed materials and partner links?

Our recommendation is to include known customer touchpoints in the destination review even when a traffic report is unavailable. A brochure, proposal attachment, customer email or partner directory may contain an address the business has distributed. The point is not to guess how many people use it. The point is to avoid overlooking a journey the company intentionally put into circulation.

Ask the team to identify which materials the business controls and which belong to another party. A staff member may be able to update a reusable email template, while a partner listing requires a separate request. Record the responsible person and the expected destination for each touchpoint. Do not mark an external listing updated just because someone has prepared a message asking for the change.

Consider a hypothetical maintenance brochure linking to a retired page. Before printing new materials, decide whether the service still exists and which approved page now explains it. If the offering changed, the brochure wording may also need correction. Updating an address alone cannot fix a promise that no longer matches the business.

Keep the original-address review separate from replacement-material work. The developer checks what happens when someone follows the older link. The business checks what its next brochure or email should say. Both are useful, but completing one does not establish that the other happened. Finish with a record of the accepted destination and the outstanding material updates.

Evidence: c-move

How can you tell whether the map covers the inventory?

Ask where the old-page list came from and what might be absent. The team may have a content export, a known URL list, navigation records or another inventory source. Request its scope and date. A short navigation menu does not by itself describe every article or service page the business has published, so the list's origin matters to the acceptance decision.

Our recommendation is to compare the map with the inventory actually used, then list unmapped rows and uncertain groups. A row with no decision should remain visible as an exception. A page that was deliberately excluded should have an explanation. This review method does not promise discovery of every possible historical URL; it makes the known limits clear enough to act on.

Shared patterns can make a large review easier, but keep meaningful exceptions separate. If a group of educational articles moves under a new path, the developer can explain the common routing treatment. The business still needs to identify articles being consolidated, corrected or retired, because those changes involve meaning as well as address structure.

Close the inventory review with a bounded statement: which source list was reconciled, which groups were reviewed and which exceptions remain. Avoid “all URLs handled” when the evidence only covers a selected sample. The broader post-launch review can then assess what the team's statement actually supports.

Evidence: c-move

What should you check after implementation?

Ask the technical owner to demonstrate the journey from an original address to its intended destination. Preserve the old URL, reached URL, observation date and result. If a route is unexpected, send that precise record back to the developer. If the reached page is technically correct but describes the wrong service, assign the meaning decision to the business reviewer.

Include different accepted treatments in the demonstration rather than selecting only easy moves. Review a retained page, a changed address, a meaningful consolidation and an intentional retirement when those cases exist in the project. This is a recommended way to examine variety, not a numerical sampling rule or proof that unseen pages are correct.

If implementation differs from the approved map, record the discrepancy before accepting the launch. A supplier may have found a legitimate reason to revise the plan, but that reason should be visible to the owner. Update the accepted decision and its evidence together so the next person does not rely on an outdated spreadsheet.

Finally, keep routing observations separate from search and business outcomes. A correct destination is useful evidence about a journey. It is not a receipt for indexing, an AI citation or an inquiry. Use the content review to check the answer at the destination and the evidence guide to interpret later observations. The completed output should show where known journeys lead and which remaining decisions need attention.

Evidence: c-move