On this page
Your website has moved, but an AI answer still links to an old URL. That observation does not tell you whether the migration is broken.
The answer might have been saved before the move. A newly collected answer might still display the old address while the link leads correctly to the replacement page. Or the old URL might send readers to an error, an irrelevant destination or outdated content.
Separate the recorded answer from what the URL serves now. The first tells you what was observed at a particular time. The second tells you whether the current route works for the request you tested.
Preserve the citation before following it
Copy the citation's actual destination, not only its visible title or displayed domain. Keep the original URL exactly as recorded, including meaningful path and query details. Save the answer, exact question, provider context and collection time with it.
Record the migration event separately. Note when redirects and replacement pages became public, and when you verified them. A migration date without a time can be insufficient when the answer and deployment occurred on the same day.
If the answer predates the move, label it as historical evidence. Repairing a live route does not rewrite a saved answer. If the answer is newer, the old address remains worth investigating, but its presence alone does not reveal the provider's internal source-selection process.
Inspect the actual route and destination
Request the exact cited URL and record the current response, any redirect steps, the final address and the relevant page content. Keep the check time and method with the result.
A browser can show a working page after following redirects or running scripts. That does not tell you which HTTP responses came first. Ask the developer or use an HTTP inspection tool to preserve the route as well as the visible destination.
Review the destination's meaning. Does it still answer the question the citation was meant to support? A successful response from an unrelated homepage is different from a successful response from the correct replacement guide.
For a permanent move, Google recommends permanent server-side redirects where possible and identifies 301 and 308 as permanent redirect statuses. This is guidance for Google Search and directing users to the moved page, not a guarantee about another provider's future citation text. Google Search redirect guidance.
Check that the migration signals agree
Use the intended old-to-new mapping to review the affected route. Google advises redirecting directly to the relevant final destination, avoiding irrelevant bulk redirects to a homepage, and updating internal links and sitemap URLs. Its migration guidance also calls for the new pages' canonical annotations to use the new URLs. Google's site-move guidance.
Check the canonical declaration alongside the content. A canonical annotation expresses a preferred URL for duplicate or similar pages; it does not navigate a reader like a redirect. Google describes redirects and canonical annotations as strong canonicalization signals and sitemap inclusion as a weaker signal. Avoid conflicting preferences across them. Google's canonicalization guidance.
Keep these checks scoped to the cited route and its replacement first. Expand the technical investigation if you find evidence of a shared template or migration-rule problem.
Distinguish the findings before assigning work
| Current finding | What it establishes | Next action |
|---|---|---|
| Saved answer predates migration; old URL now reaches the correct page | Historical citation plus a working current route | Preserve the record; inspect a later comparable answer if useful |
| New answer displays the old URL; redirect reaches the correct replacement | Old address remains in the observed answer, but tested navigation works | Record both facts and monitor relevant new observations |
| Redirect reaches the wrong page or a loop | Current delivery problem for the tested route | Correct the mapping and recheck it |
| Final address is correct but content is obsolete or missing | Destination content does not meet the requirement | Investigate the publication or delivery path |
| Old URL still serves a duplicate page with conflicting signals | Migration state needs technical review | Reconcile the intended behavior with the developer |
| Current request cannot be completed | Live route remains unverified | Record the failure and arrange another check |
Several findings can coexist. A correct redirect does not make a wrong factual statement in the answer correct. An accurate answer does not make a broken destination acceptable.
Use a concrete acceptance record
Illustrative example only. The following paths and events describe a fictional site.
An answer saved on October 6 cites /guides/group-booking. The team moved that guide to /help/group-reservations on October 5. An inspection on October 7 finds that the old path redirects to the homepage.
The actionable problem is the incorrect current destination. A developer task can specify:
- Affected URL: the exact old path preserved from the citation.
- Intended destination: the replacement guide in the approved mapping.
- Required behavior: the intended permanent redirect reaches that guide without a loop or irrelevant intermediate page.
- Content requirement: the replacement guide contains the verified group-reservation instructions.
- Evidence of completion: a dated route check and a readable check of the final page.
After the repair, the team verifies the route on October 8. The saved October 6 answer still contains the old URL. That is expected for an unchanged historical record, and it does not invalidate the route repair.
A later answer might cite either address or a different source. Preserve that as a new observation. The acceptance condition for the developer task should be the functioning route and correct destination, not a promised change in the provider's next answer.
Investigate content freshness only when the evidence points there
If the final page contains an older version, compare it with the approved published content. The browser, public HTTP response and crawler-facing delivery may provide different observations. Record which one actually shows the mismatch before assigning a cache or rendering fix.
Use the content freshness monitoring guide for that investigation. An old citation URL alone is not evidence that your own cache is stale. Clearing your site's cache also does not establish that an external service's saved or indexed material changed.
Keep the original citation URL in the evidence even when you add the resolved destination to your report. If several old paths resolve to one new page, show that mapping separately; silently replacing the stored addresses would erase part of the observation.
Decide what to observe next
After a verified repair, repeat the relevant reference questions when another observation will inform a decision. Keep question wording and known provider context comparable, and show failed collections separately from successful answers.
Track three outcomes independently: whether the old route works, whether the destination remains correct and which URLs appear in newly recorded answers. You can close a confirmed route defect while continuing to observe citations.
In Prerender Buddy, use saved AI Visibility results for the answer evidence and dated page checks for the technical evidence where those features are available. Add any redirect-chain or content inspection that the available evidence does not expose. Do not infer a complete migration test from an aggregate health result.
A useful report can then state exactly what is known: the old citation was observed on one date, the route was verified on another, and later answers were checked under a defined scope. That is enough to assign and verify real work without inventing a timeline for citation replacement.