Notes / Siteworks
What happens to old URLs when your service website is redesigned?
A redesigned site needs a plan for the links customers already have. Here is what to ask your team to preserve, test, and hand over before launch.
By Edu Rigonato. Published Sep 29, 2026. 10 min read.
The new homepage is ready. The service pages look clearer, the mobile layout works, and the contact button is easy to find. Then a customer opens a link saved from an earlier conversation. It leads to an error—or lands on the homepage with no explanation of where the service went.
That is a different route into the business from the polished navigation you just reviewed. A redesign needs to account for both.
Before launch, ask your team for a list of important old page addresses, the intended outcome for each, evidence that those outcomes work, and a named person who will handle problems afterward. Keep useful addresses where practical. Where an address must change, agree on a relevant destination. Where content is genuinely retired, make that decision explicit.
You do not need to configure the server yourself. You need enough visibility to understand what the team is changing and what its launch checks actually cover.
The home-services examples below are fictional. A separate example from VisionOn’s recent website relaunch shows how we checked an approved redirect map after publication. It documents routing checks, not search or sales results.
Start with the addresses customers already use
Ask for the old URL inventory while the current site is still available. A URL is the address of a page or file. The inventory is a working list of the addresses the project needs to account for, including pages that will no longer appear in the new menu.
A current-site crawl is a useful starting point. It follows links and records what it finds. But ask what other records the team will use: existing sitemaps, search and analytics reports, relevant backlinks, downloads, and known campaign destinations. Google’s site-move guidance describes combining URL information from sources such as sitemaps, logs and analytics when planning a move.
Frequently asked questions
Does changing the design mean we have to change our URLs?
No. Ask whether the current addresses can continue serving the same resources on the redesigned site. Platform constraints and content decisions can justify changes, but visual changes alone do not make new addresses necessary. Request a reason for each proposed change.
Should deleted pages always redirect to the homepage?
No. Use a destination that meaningfully replaces the old content. When there is no suitable replacement, a proper 404 or 410 can be appropriate. A helpful error-page message and navigation can assist visitors without pretending the removed page has moved somewhere relevant.
Is a 308 redirect wrong if the plan says permanent redirect?
Not necessarily. Google recognizes both 301 and 308 as permanent redirects. They differ in HTTP request-method handling, so the developer should choose deliberately. Ask whether the response and destination match the intended behavior, rather than judging the configuration by a familiar number alone. See <a class="inl" href="https://developers.google.com/search/docs/crawling-indexing/301-redirects">Google’s redirect guidance</a>.
Can we remove the old redirects after a year?
Do not make it automatic. A year is general Google migration guidance, not proof that nobody uses the old addresses anymore. Review known external links, ongoing business references and maintenance dependencies with the responsible person before removing them.
Can the team guarantee that search traffic will not fall?
No. Ask for clear commitments about mapping, testing, monitoring and fixing problems within the agreed scope. A promise about those deliverables is different from a guarantee about rankings, traffic or a recovery date.
Before signing off on the redesign, ask to see the old-link plan alongside the new pages. The website should make sense to someone arriving through today’s navigation and someone following a link your business shared months ago. Give both journeys an intentional outcome, and keep the responsibility for maintaining them clear.
Explore Siteworks