Freeze the old-to-new mapping
Write down the exact old URL and the intended new URL before changing links. Include the language, trailing slash convention and any section fragments that people use. Confirm that the new page contains the resource previously promised. A renamed route is not permission to substitute an unrelated page with a similar title.
Keep this mapping in the change record together with an owner and a rollback reference. If several people edit the same content, agree which URL becomes authoritative before they start. This article covers references after a known slug change; discovering a missing page or choosing a replacement for deleted material requires a different decision.
Find references in both content and shared components
Search the maintained content source for the old path and its absolute URL. Inspect navigation, related-resource blocks, category listings, breadcrumbs and reusable snippets, as well as ordinary article links. Separate active source references from archived examples or historical documentation where an old URL may be intentional.
Use an internal-link crawl as a second view, with its scope and rendering settings recorded. A source search can miss database-generated links; a crawl can miss isolated pages or content behind access controls. Put each confirmed reference in a table with source page, editing location, intended destination and completion status. Do not claim full coverage from one search.
Update the source rather than relying on the redirect
Change maintained internal links to the new destination using the approved mapping. Edit a shared component once and regenerate affected pages where necessary. Avoid a blind text replacement across unrelated slugs, code examples or other language routes. For section links, check that the target identifier still exists on the new page.
Google’s migration guidance calls for updated internal links, new self-referencing canonical URLs and updated language annotations and sitemaps. Check those items separately from visible links. A redirect from the old address can preserve access for existing references, but it does not demonstrate that your own link sources were corrected.
Illustrative example: a renamed preparation guide
Suppose a guide changes from /en/visit-prep/ to /en/maintenance-visit-checklist/. Its content remains the same. An inventory finds a header shortcut, two article references and a related-resource component using the old path. These are fictional counts to demonstrate a repair record, not findings from a customer website.
The editor updates those sources and tests the fragment #documents on the new page. The Arabic counterpart keeps its existing route, while its alternate-language reference is updated to the new English URL. The old English route is tested separately for the intended redirect. The record distinguishes source edits, language annotations and redirect behavior so one successful check cannot hide another unfinished task.
Verify the rendered result and retain evidence
After regeneration, open the affected pages and inspect their actual link destinations. Confirm that the new URL loads the expected content and that old links are absent from the agreed active scope. Search the generated output as well as the editable source if the site has a build step. Repeat the crawl with comparable settings and document intentional exceptions.
Save the mapping, changed locations and verification date. Monitor unexpected old-route requests to locate references missed in the initial inventory, without assuming every request originates on your own site. An SEO audit can supplement this record with technical link checks. A successful redirect or clean crawl is not evidence that Google has already replaced the old URL in its index.