Redesigning your website? Map the old URLs before launch

By Noe Guerrero III

Before replacing a website, make a list of its existing page addresses and decide what should happen when someone opens each one after launch. Some addresses can stay. Others need a redirect to the right replacement. A page you're deliberately removing needs a different decision.

That list becomes your URL map. Add expected responses, test results, and the person responsible, and it becomes a launch checklist your business can actually review.

I’d want to see that file before approving a redesign. The new homepage can look finished while a link on a customer's saved estimate still leads nowhere.

Keep an address when it still does the job

A new layout doesn't automatically need a new URL. If /services still describes the same services, ask whether it can remain at that address. Changing a heading or replacing a photograph doesn't, by itself, give a customer a reason to use a different link.

Decide the proposed page structure before building redirect rules. Otherwise, the developer may map an old page to a destination that gets renamed again during the design review.

Give each proposed change a reason: two genuinely overlapping pages are becoming one, a service has moved into a clearer section, or an old offer has ended. “The new template generated this address” deserves a closer look before it becomes the permanent plan.

Build the inventory from more than the menu

Start with the current website's page export and sitemap, then compare them with a crawl and the URLs appearing in available analytics, server logs, or Search Console. These sources may uncover pages that aren't in the navigation. Include useful downloadable files and campaign destinations, too.

Ask staff for links they've shared in estimates, email signatures, printed QR codes, and business profiles. A small list from the office can reveal an important customer route that a design review misses.

Keep the original address exactly as found. Record where it came from and what the visitor expects there. Don't silently remove a query string, such as ?service=repair, until someone checks whether it selects content or passes information the business needs.

Mark missing information as unknown. If nobody has access to historical analytics, continue with the records available and document that gap. You can prioritize known customer links without inventing traffic or declaring every other page unimportant.

Give every address a clear decision

Use one row per old address. My working sheet would include the old URL, its purpose, the decision, the intended destination, the expected response, the reviewer, and the test result.

Separate three decisions:

• Keep: The page remains at the same address with suitable content.

• Move or combine: A relevant replacement exists, and the old address should send visitors there.

• Retire: The content is gone and there is no suitable replacement.

For permanent moves, Google's redirect guidance recommends a permanent server redirect where possible. Both 301 and 308 indicate a permanent move. These responses also help communicate the preferred destination to Google.

For retired content with no similar replacement, Google advises returning 404 or 410. A friendly error page can still provide navigation, but it needs the correct HTTP response; showing “not found” with a successful 200 response can create a soft 404. Google's crawling-error guidance explains the difference.

The owner should approve the content decision. The developer should choose and implement the technical response. Neither person should have to guess what the other intended.

Work through a small map before approving the whole file

Imagine a furniture workshop in McAllen redesigning its website. This is a hypothetical example, not a client migration. The team is keeping its contact page, combining two repair pages, moving its refinishing page, and removing an expired sale with no replacement.

The table uses short paths for readability; the working file should identify the complete old and destination addresses. The 301 entries are the permanent-redirect choice for this example.

Now review the actual replacement content. Does the combined repair page explain both chair and table repairs? Can someone arriving from the old refinishing link still find that service? A destination with the right name but missing information isn't ready just because it loads.

For a business serving customers in English and Spanish, review each language's old pages separately. Preserve the intended language where a suitable replacement exists. If the translated replacement isn't ready, record that as an unresolved decision before launch.

Test the rules against the approved map

Ask the developer to produce a report from the proposed redirect configuration before release. For each row, the report should show the requested address, first response, any intermediate destinations, final URL, and final response.

Then compare what happened with what the owner approved. For the hypothetical refinishing page, the expected result is a permanent redirect to the exact refinishing destination, followed by a successful response containing that service's content.

Make failures specific. “Wrong destination” needs the expected and observed addresses. “Broken redirect” needs the actual response or loop. A useful report lets the next person reproduce the problem without repeating the entire investigation.

Check these cases deliberately:

• An address that moves, one that stays, and one that is retired.

• Old links with the trailing slash or capitalization variants people actually use.

• Query parameters that select a service or carry campaign information.

• A newly invented, nonexistent address that should remain a genuine not-found page.

• An exception to any broad redirect rule, such as a retired page inside a moved section.

A rule that sends every unknown address to one service page may pass a quick homepage check while hiding mistakes elsewhere. Ask for an explicit list of exceptions rather than relying only on a general pattern.

A browser visit confirms the experience, but the response report tells you whether the intended redirect actually happened. Use both. For a modest business site, request checks for the full map, with closer human review of the pages that customers rely on most.

Align the destination pages with the map

A canonical identifies the preferred URL for duplicate or very similar content. It doesn't replace a redirect that moves visitors. Google's canonical guidance recommends consistent signals: self-referencing canonicals on preferred pages, internal links to those addresses, and no conflicting canonical targets across methods.

For the workshop example, the new refinishing page should identify its intended public address rather than an old path or preview domain. Check more than the homepage: a shared template mistake can affect every service page.

Have the developer report the canonical found on each mapped destination. Separately, check that pages intended for public search don't retain a preview site's noindex instruction or crawler block. Keep deliberate restrictions on private areas intact.

Review the new site's navigation and contextual links against the map so they use the final addresses. Add a check for downloadable files when they form part of the customer journey; a successful service-page redirect doesn't prove its brochure link works.

The sitemap is a separate output. Google's sitemap guidance calls for complete, absolute URLs and the preferred versions of pages. Check the generated file against the intended public destinations rather than assuming a sitemap plugin selected them correctly.

Repeat the checks on the public website

Testing a preview proves only what that environment did. After launch, repeat the URL checks against the public domain and open the important routes on a phone and computer. A hosting rule or existing redirect may behave differently from the development setup.

For the furniture workshop, start from the old refinishing address, read the new page, and use its inquiry link. Then open the contact page directly and request the retired sale address. Record the actual outcome of each route with a timestamp.

Keep business approval separate from technical completion. The developer can confirm the response codes, while the owner confirms that the replacement page describes the service correctly. Mark a row complete only when both required checks pass.

Submit the updated sitemap through the appropriate webmaster account and review reported processing errors. Google treats sitemap submission as a hint, so a successful submission isn't confirmation that every page has been crawled or indexed.

If something fails, assign an owner and a next action. Correct the rule or destination, repeat the affected checks, and save the new result. Don't turn an unexplained failure into a passing row because the rest of the site looks fine.

Keep the map after launch

Hand over the approved map, the implemented rules or their location, the dated test report, and the unresolved items. Identify who can change the rules and where staff should report an old link that fails. These records should stay with the business when the project ends.

Set a follow-up review for unexpected not-found requests and customer reports, then compare them with deliberate retirements. A planned 410 for an ended sale and a broken link to a current service need different responses.

Google's site-move guidance advises keeping redirects as long as possible, generally at least a year, and notes that search visibility can fluctuate during a move. A launch check isn't a guarantee that rankings will stay unchanged. Agree on ongoing review and redirect retention before project support ends.

The map belongs alongside the account, email, and launch responsibilities covered in our McAllen website rebuild guide. For a redesign with RGV Web Design's web development services, bring your current site and the old links your team still uses. That gives the project a concrete starting point: a decision for each address and evidence that it works as intended.