Canonical URLs and redirects: a practical developer guide

A canonical URL is the version of a page that you want search engines to treat as the main version when several URLs contain the same or similar content. A redirect sends a user and crawler from one URL to another. They solve related problems, but they are different controls.

Google's canonicalization guidance recommends using consistent signals: redirects, rel="canonical", internal links, and a sitemap should point to the same URL choice.

Choose one URL format

Decide the public format before you add metadata. Make these choices explicit:

• HTTPS or HTTP. Use HTTPS for the public site.
• www or the bare domain.
• A trailing slash or no trailing slash.
• One case and path spelling for every route.

For example, choose https://example.com/docs as the canonical URL. Then link to that address, list it in the sitemap, and make alternate forms redirect to it. Do not let the page produce a canonical URL that disagrees with the address users see.

Use redirects when a URL moved

Use a permanent server-side redirect when the old URL should no longer be the public address. HTTP 301 and 308 are common choices. Use a temporary redirect such as 302 or 307 when the original URL should remain the long-term address.

Keep redirects direct. A chain such as /old to /intermediate to /docs adds work for browsers and crawlers. Update internal links to /docs and keep the old redirect for as long as users and external sites may still use it.

Google explains the difference between permanent and temporary redirects. Pick the status based on the intended lifetime of the move, not on which code happens to work in a local test.

Add a self-referencing canonical

For a unique HTML page, add a canonical link to its chosen public URL:

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

Render the absolute HTTPS URL that matches the deployment. Avoid generating a canonical from an untrusted request host. If the site supports more than one hostname, configure the preferred host and redirect the other one.

A canonical is a signal, not an access control. It does not hide a page, stop a crawler, or replace authentication. Keep private content behind access controls and leave private URLs out of public navigation and sitemaps.

Keep links and sitemap entries aligned

Internal links help search engines discover and understand your site. Link directly to the canonical URL instead of linking to a URL that redirects. Put the same canonical URLs in sitemap.xml.

Use robots.txt versus sitemap.xml to check the crawl rules separately. A sitemap can list a URL, but robots.txt can still block its path. That creates conflicting instructions and makes the page harder to evaluate.

Inspect the deployed response alongside the source files:

curl -sSI https://example.com/old
curl -s https://example.com/docs | grep -i canonical

Confirm the redirect status, final URL, content type, and canonical value. Follow the same check for the www and non-www hosts if both resolve.

Common mistakes

• Every page points its canonical link to the homepage.
• A staging hostname appears in production canonical tags.
• The sitemap lists http while the site uses https.
• Internal links use /docs/ while the canonical uses /docs.
• A temporary redirect is used for a permanent URL move.
• A redirect points many unrelated pages to one homepage.
• A page is blocked by robots.txt even though the sitemap lists it.

Slop Audit checks the final URL, redirects, canonical URL, internal links, and sitemap evidence when those files are available. It reports the observed values. It cannot decide which URL your business should use, so make that choice in the release configuration first.

Canonical URL sign-off

preferred host → HTTPS → redirect alternates → self-canonical
→ direct internal links → matching sitemap → deployed response check

Run the check after deployment and after any domain, router, or trailing-slash change. URL consistency prevents a small configuration choice from turning into a crawl and maintenance problem.