How to Check Old Links After a Website Rebuild

Start with what the old link promised

When we replaced Automate Planet’s website, old addresses still mattered because people could encounter them outside the new navigation. Our migration work included a list of old paths, relevant replacement destinations and checks for missing sections. The useful implementation lesson is that “the homepage loads” is an incomplete acceptance test for a rebuilt site.

Write down why someone would open each old address. An integrations link should reach integration information; a contact link should reach contact options. A renamed company page should reach the new company page. This gives the business owner a way to judge a redirect without needing to understand the server configuration.

Google’s site-move guidance recommends mapping old URLs to their replacements and avoiding irrelevant mass redirects to a homepage. Consolidated content can have a shared destination when it answers the old pages’ purpose. A purposeful contact-section redirect is different from sending every missing page to the top of the homepage.

What we observed on our own site

On October 26, 2026 at 9:04 AM Pacific, we checked three deliberately selected legacy addresses: a renamed about page, a contact section and an integrations section. Each address was requested with and without a trailing slash. All six initial responses were HTTP 301 and pointed directly to the expected destination. Direct requests to the three destination pages returned HTTP 200.

The two destination section IDs were found in the returned HTML. That is a structural check, not proof that every browser positions the section perfectly. We also checked that each destination’s declared canonical URL matched the final page address, without its section fragment.

This sample was selected to exercise different destination types. It was not random and does not establish a site-wide success rate. The unknown-address check covered one path. These observations do not establish that every historical URL, hostname, query string or browser cache behaves the same way.

A repeatable check from old address to useful page

1. Capture the exact old URL. Keep its spelling, hostname and any query string from the link someone actually used. For our sample, the hostname was automateplanet.com and the selected URLs had no query strings.
2. Inspect the first response without automatically following it. Record the status and destination. Our check used read-only HEAD requests for the old addresses. Following redirects immediately would conceal the first response.
3. Request the destination directly. We used GET requests for the three final pages. A final 200 response confirms that the page was served; also read the page to decide whether it answers the original need.
4. Check any section after the # symbol. Confirm that the destination HTML contains the matching section ID, then inspect the arrival in a browser. Our recorded sample checked the IDs; visual arrival remains a separate acceptance step.
5. Try one address that should not exist. Record the actual response status as well as the visible recovery navigation. A page that says “not found” is not enough to establish a 404 response.
6. Save the date, URLs and results. Recheck failed rows after a fix and keep the original observation. Do not replace a failure with a pass without recording what changed.

Google’s redirect documentation identifies 301 and 308 as permanent server-side redirects. Our sample returned 301. Record the actual response instead of describing all redirection as permanent.

Give the business owner a clear acceptance sheet

This is an original worksheet based on our migration checks. Use one row per old address, and add the person responsible for any unresolved item. It is a proposed review method, not a claim that we tested every condition on every website.

For prioritization, begin with links you know people use: addresses in search reports, customer messages, directory listings and your own navigation. Expand from a sample to the complete agreed inventory before calling a migration fully checked. Keep unusual cases visible instead of hiding them inside a single completion percentage.

Keep delivery checks separate from search results

A redirect result answers “where does this request go?” It does not answer “has Google updated this listing?” or “did this visitor become a customer?” Our sample did not inspect Search Console, traffic changes, form completion or purchase outcomes. It also did not test alternate hostnames, query-string preservation, every old path or external sites linking to us.

Google’s guidance recommends direct destinations, updated internal links and canonical URLs, a current sitemap, and retaining redirects for at least a year in general. Recrawling and processing can take time. Treat the HTTP record and later search reporting as different evidence sets.

Our next-step method is to keep an issue list with the old address, expected destination, observed result, responsible person and recheck date. Fix the path first, then monitor discovery and inquiries over a defined period. The search evidence guide explains how to read visibility reports without turning impressions into customer counts.

If you are replacing a website, include the old-link inventory and acceptance sheet in the project scope alongside the new design. Explore business website services and SEO services, then choose the package for your industry. The useful buying question is which old journeys will be preserved and how the team will demonstrate that they work.

Common questions

Explore the relevant services

• Business Websites
• Seo

Review the current package scope and ask our AI about fit before purchasing.

Sources and editorial approach

• Google Search Central: Site moves and URL changes
• Google Search Central: Redirects and Google Search
• Automate Planet: legacy integrations address used in this sample

How this page was prepared. AI-assisted writing based on documented Automate Planet work and the sources linked here. This is our implementation account, not an independent evaluation.

The October 26, 2026 observations are a small point-in-time check of our own public website. They are not a complete migration audit, a client outcome study or evidence of restored indexing, search traffic or sales. No forms, purchases or messages were submitted.

Send a correction or question.