Changing website URLs: what should redirect where?
Approve the destination of each changed address before launching a redesign. Preserve stable useful URLs, match replacements to the original customer task, and test both Arabic and English journeys. This guide turns that decision into a practical mapping and acceptance record.
In this guide
Start with the reason a visitor uses each address
Keep a useful URL when the redesign does not need to change it. When an address must change, approve its destination according to the job the old page performed. A supplier's specification page should lead to the relevant specification or product page, not merely to whichever new page looks attractive. The decision belongs in the project brief before launch.
Begin with a plain-language inventory: page purpose, language, current address, planned address, owner and decision. Include pages used in quotations, advertisements, saved messages and downloadable brochures. Search data can help prioritize checks when available, but a page with unknown traffic may still support an important customer task. Do not silently delete it because a report lacks a row.
Separate a new design from a new address
Changing the colours or layout does not inherently require changing every URL. Distinguish a hosting move, a design change, a content reorganisation and a domain change. Each introduces a different set of decisions. If a supplier proposes all of them at once, ask what business requirement each one solves and which can be separated to make acceptance clearer.
Google publishes different guidance for infrastructure moves and moves involving URL changes. Its URL-migration guidance calls for an old-to-new mapping and appropriate permanent redirects, followed by checks and monitoring. That does not make a redesign risk-free or establish a fixed recovery timetable. The practical buyer requirement is an explicit migration scope and an accountable person for it.
References: Google Search Central: moving a site with URL changes · Google Search Central: redirects and canonical destinations
Approve a mapping with reasons, not a list of guesses
The following worksheet is an original planning example for an invented supplier. Replace the example paths with actual addresses; these are not existing Biaway pages or implementation instructions for every server. Give unresolved rows an owner and a deadline. A blank destination should mean a decision is pending, not permission to redirect somewhere convenient.
Keep the language of the destination deliberate. An Arabic page and its English translation may share a topic, but sending all Arabic visitors to English can break the customer journey. Where a translation is being retired or rewritten, explain the decision and its effect before release.
Scroll the table sideways to read every column.
| Old item | Decision | Destination or response | Acceptance evidence |
|---|---|---|---|
| Useful service page, unchanged purpose | Preserve address | Same working page | Content and enquiry route still match |
| Service renamed, meaning preserved | Map to its replacement | Corresponding new service page | Correct final page and language |
| Two genuinely duplicate pages | Approve consolidation | One page covering the combined intent | Owner confirms no useful detail was lost |
| Withdrawn offer, no replacement | Record removal | Appropriate not-found response | Helpful navigation, no false replacement |
| Arabic and English pair | Map both independently | Equivalent pages in each language | Language switches reach the right pair |
| Linked product brochure | Keep or replace deliberately | Approved document or relevant replacement | Download and page references tested |
Work through one quotation journey
Suppose a fictional equipment supplier changes its catalogue structure. Its sales team has already sent buyers a pump specification link, an Arabic installation page and a PDF. The new designer proposes a single polished catalogue page. Before accepting that proposal, the owner checks whether buyers can still identify the exact pump, read installation conditions and obtain the approved document.
If the combined catalogue cannot answer those tasks, redirecting everything there is an incomplete solution. Keep a useful product page or create a genuinely equivalent destination within the agreed scope. Record which information moves and who approves it. This example demonstrates a content decision; it does not claim that a particular redirect produces traffic, leads or rankings.
Check the new pages around the redirects
A redirect is only one part of the release. Ask the implementer to align internal links, self-canonical addresses, language alternates and the sitemap with the approved new URLs. Google advises avoiding irrelevant bulk redirects and unnecessary redirect chains. If content is intentionally removed without a replacement, the response should accurately represent that removal.
Turn those requirements into understandable evidence. Request a compact record showing the old address, first response, final address, final status and language. Open the final page yourself and check its purpose. A green technical check cannot tell you whether the destination describes the right product or whether the Arabic wording still makes the approved promise.
References: Google Search Central: moving a site with URL changes
Preserve real Saudi coverage during the move
For a hypothetical supplier serving Hofuf and Mubarraz within Al Ahsa, a collection-information page may contain details that a general Saudi Arabia homepage does not. Keep those instructions accessible when reorganising the website. If Dammam and Khobar buyers use a different delivery or quotation route, map their relevant pages according to that task rather than merging them because both mention the Eastern Province.
Riyadh and Jeddah buyers may use remote sales, shipping or another confirmed arrangement. Preserve those actual conditions without creating a separate destination for every city name. Biaway works online: a migration review can be coordinated remotely, while the business confirms its operational facts. This scenario does not imply Biaway branches, clients or delivery facilities in those places.
Agree what happens if a launch check fails
Before launch, assign someone who can approve a pause or rollback. Keep the previous release and necessary configuration recoverable, and decide how new orders or enquiries created during the transition are protected. A static archive alone may not recover changing application data. The plan should match the platform instead of promising that every website can be restored with one click.
Test a representative set before release, then verify the public addresses after deployment. Prioritize quotation links, active campaign destinations, both languages and downloads. Record failures separately from accepted exceptions. Avoid closing the old service or deleting the mapping merely because the homepage is live; the transition needs an agreed monitoring and redirect-retention responsibility.
Judge the release using evidence and a dated baseline
Save the original inventory, approved mapping, release date and test results together. Later Search Console observations should distinguish old redirecting URLs from new intended pages, and actual indexed status from a successful live check. Compare available complete reporting periods carefully; missing measurements remain unknown. A change in traffic cannot automatically be attributed to the redesign when content, campaigns or seasonality also changed.
For the quotation, separate design work, content migration, redirect implementation and post-launch checks. Ask Biaway to assess those tasks against your real page list and access arrangements. The useful deliverable is a controlled customer journey with clear responsibilities, not a guarantee that Google will preserve every position or finish processing the move by a promised date.
References: Biaway: repair versus redesign · Biaway: moving website hosting
How this guide was prepared
Prepared with AI assistance, with platform and accessibility claims checked against the primary sources below at publication. The planning frameworks are Biaway’s editorial recommendations. Examples labelled illustrative are not client stories or measured results. Platform features and requirements can change.
Your questions.
01Must every redesigned page receive a new URL?
No. Preserve a useful stable address unless a real requirement justifies changing it. Visual redesign and URL restructuring are separate decisions.
02Can all old pages redirect to the homepage?
That can mislead visitors when the homepage does not replace their original task. Google warns against irrelevant bulk redirects; map to a suitable equivalent or represent a genuine removal accurately.
03Does a redirect mean the old URL has failed indexing?
An old URL that intentionally redirects is normally not the page you want indexed separately. Inspect the final intended URL and keep migration behavior separate from its actual indexing status.
04Who should approve the mapping?
A business owner or knowledgeable content approver confirms the meaning and service facts; the implementer verifies technical behavior. Both checks matter.