After a URL migration, use one old-to-new URL map to update public links, canonical declarations, redirects, and sitemap entries. This Mac desktop workflow shows how to make those changes agree and verify the published result.

The task here is a small collection of public HTML documents moving to new paths on the same website. All example addresses and page names are synthetic. You need access to the publishing system, its redirect settings, and the relevant Search Console property to perform the full workflow.

What should agree after the migration?

For each moved document, choose one final destination. Links you control should point there directly, the destination should identify itself as canonical, and the current sitemap should list that address. The old address should redirect to it. Google describes redirects and canonical annotations as strong canonicalization signals, while sitemap inclusion is a weaker signal. These methods can reinforce one another, but Google ultimately selects the canonical. Google’s canonicalization guidance.

These mechanisms have different jobs. A redirect handles a request for an old address. A public link determines where a reader goes next. A canonical declaration identifies the preferred URL for a document; WHATWG defines that meaning for the canonical link type. A sitemap supplies a list of preferred URLs for discovery. Updating one does not edit the others. WHATWG HTML Standard: canonical link type, Google’s sitemap guidance.

Use this agreement table as a practical acceptance check. It is a workflow derived from the documentation, not a Google scoring system.

Surface Expected result for the synthetic Colors document
Old address https://example.com/notes/colors.html permanently redirects to the destination
Destination https://example.com/library/colors/ serves the Colors document
Navigation and document links Point directly to https://example.com/library/colors/
Destination canonical Identifies https://example.com/library/colors/
Current sitemap entry Lists https://example.com/library/colors/

Build one mapping before changing individual settings

On your Mac, open a spreadsheet or plain-text editor and record each old address beside its intended destination. Google recommends preparing an old-to-new URL mapping as part of a move. Keep a copy of the original list so that replacing sitemap entries does not erase your record of addresses that still need redirects. Google’s site-move guidance.

Document Old path Final path
Colors /notes/colors.html /library/colors/
Palette /notes/palette.html /library/palette/
Shapes /notes/shapes.html /library/shapes/

For each row, record where you must make changes: the page editor, shared navigation, canonical setting, redirect setting, and sitemap generator. Add separate check columns for the public response and Search Console inspection. This turns a vague instruction to “update URLs” into a finite set of edits and observations.

Check the destination content before accepting a mapping. If two old documents have become one useful consolidated document, both can redirect there. Avoid sending unrelated documents to a generic homepage; Google warns that irrelevant redirects can be treated as soft 404s. Google’s redirect-mapping recommendations.

Update public links and check relative paths

In your publishing editor, use the mapping to update navigation, document indexes, related-document links, and links inside the article text. If the system generates navigation from page records, change the underlying records or template rather than repeatedly correcting generated output. Review each replacement before saving, especially where the old path also appears in explanatory examples.

A path change can alter a relative link’s destination even when its text stays identical. The WHATWG URL Standard resolves relative references against a base URL. For the illustrative cases below, assume the document has no explicit base override. WHATWG URL Standard.

Document URL Link value Resolved destination
https://example.com/notes/colors.html palette.html https://example.com/notes/palette.html
https://example.com/library/colors/ palette.html https://example.com/library/colors/palette.html
https://example.com/library/colors/ /library/palette/ https://example.com/library/palette/

These synthetic resolutions were checked with JavaScript’s URL API. The unchanged palette.html value now points inside the Colors directory, so a successful text replacement elsewhere would not catch the problem. For this small collection, using the intended root-relative path makes that destination explicit. If moving to a different host, use the correct absolute address or verify that each root-relative link remains on the intended host.

Open the published Colors document in your Mac browser and follow its Palette link. Check both the displayed document and the final address. Repeat for shared navigation and any section links. If a link uses #swatches, confirm that the destination still contains the corresponding section identifier; the path map alone cannot establish that.

Set canonicals and permanent redirects at their source

For each new HTML document, set its canonical to the final absolute URL. Google recommends absolute canonical URLs and accepts the HTML canonical element in the document’s head. If your publishing system has a canonical field, enter the address there and inspect what it generates. Google’s canonical implementation instructions.

For the Colors page, the following is a metadata fragment to place within the existing document head, not a complete HTML page:

<link rel="canonical" href="https://example.com/library/colors/">

Check whether the host also sends a canonical through an HTTP Link response header. Google supports both methods but recommends choosing one because maintaining both can introduce conflicting destinations. Correct the template or setting that produces the value, so the next publication does not restore an old address. Google’s canonicalization methods.

Configure the old address to return a permanent server-side redirect to the destination. RFC 9110 defines 301 and 308 as permanent redirects and describes the destination in the Location header. The distinction includes request-method handling: 308 preserves the method, while 301 permits historical POST-to-GET behavior. For ordinary document retrieval, Google treats both as permanent redirect signals. RFC 9110: HTTP Semantics, Google’s redirect documentation.

The exact configuration depends on your host or publishing system. Browser editing cannot create an HTTP response rule by itself. If your platform cannot configure server-side redirects, use its documented hosting configuration or ask the hosting operator to implement the map. Google documents instant meta refresh as a fallback when server-side redirects are unavailable; it recommends JavaScript redirects only when the other approaches cannot be used. A canonical declaration alone does not move a visitor to the new address. Google’s supported redirect approaches.

Regenerate the sitemap from the same destinations

Update the source of the sitemap, then regenerate it. A manual correction to a generated file is easy to lose on the next build. For this migration, the current sitemap should contain the final Colors, Palette, and Shapes URLs rather than their old paths.

Google requires fully qualified absolute URLs and UTF-8 encoding for sitemaps. If you only need to list web pages, a text sitemap is supported: one URL per line, with no headings or commentary. The complete synthetic three-page example would be:

https://example.com/library/colors/
https://example.com/library/palette/
https://example.com/library/shapes/

Google’s sitemap formats and requirements.

If the site already generates an XML sitemap, retain that supported format and update its URL entries. Use accurate modification dates when supplying lastmod; Google says this value should reflect significant page updates. Do not automatically replace every date merely to make the sitemap appear recent. Google’s XML sitemap guidance.

Verify the public result from your Mac

Check the deployed output, because an editor preview cannot establish the HTTP response at the public address. Open Terminal on your Mac. The following diagnostic commands use synthetic addresses: replace them with the corresponding public URLs from your own map before running. No live migration result is implied by these examples.

old_url='https://example.com/notes/colors.html'
new_url='https://example.com/library/colors/'

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  --location --max-redirs 5 --output /dev/null \
  --write-out 'status=%{http_code}\nfinal=%{url_effective}\nredirects=%{num_redirects}\n' \
  "$old_url"

curl --silent --show-error --connect-timeout 10 --max-time 30 \
  "$new_url"

The first command displays the initial response headers without following the redirect. The second follows redirects and reports the final status, address, and redirect count. The third retrieves the destination markup for inspection. These options are documented in the curl manual.

For a straightforward mapped page, expect an initial 301 or 308 with the intended Location, followed by the final address serving the document successfully. Inspect the returned markup for the canonical. Also read the document in your browser: an HTTP success response alone does not prove that the correct content arrived. Google recommends redirecting directly to the final destination rather than building chains. RFC 9110: status codes, Google’s site-move guidance.

Use the following diagnostic order when a row fails. It keeps repairs tied to observable output.

Observation Next action
Old URL redirects to an unintended page Correct that mapping or redirect rule
Redirect reaches another redirect Point the old address directly at the final destination
Correct page has an old canonical Correct its metadata source and republish
Navigation still visits an old path Update the originating link or shared template
Sitemap still lists old paths Correct the generator input and regenerate
Terminal reports a timeout Repeat the check after resolving the connection problem; record the test as incomplete

Submit the sitemap and distinguish live checks from indexing

In Search Console, select the property covering the new URLs and use the Sitemaps report to submit the public sitemap address. Google documents this report as a submission method that also exposes processing errors. Submission is a discovery hint, not an indexing guarantee. Google’s sitemap submission instructions.

Inspect a new document by entering its complete URL in Search Console’s inspection bar. Use the live test to investigate current accessibility and potential indexability. For Google’s canonical choice, use the indexed result and its Google-selected canonical field. The live test cannot predict canonical selection. Search Console URL Inspection tool.

This example changes paths within one host, so the Change of Address tool does not apply. Google directs publishers making path moves to implement redirects and update sitemaps. The tool is intended for domain or subdomain moves after the site has moved and redirects are in place. Search Console Change of Address tool.

Keep the mapping as your maintenance record. Mark a row complete only after the public redirect, destination content, links, canonical, and sitemap agree; record Google’s later indexing observations separately. Retain redirects for as long as possible—Google’s general migration guidance recommends at least one year—and continue using the final addresses in future document edits. Google’s migration guidance.

Sources