Static implementation guide
Canonical URLs Across Origins
Keep duplicate origin and gateway responses aligned by declaring one stable public URL in metadata, links, and the sitemap.
Last updated 2026-08-22
Choose one public identity
A rewritten page can be reachable through both the public gateway and the underlying production origin. The content may be identical, but the hostnames are not. A canonical link tells indexing systems which address represents the durable public identity. In this architecture that address always uses the gateway domain, even when the HTML is fetched directly from the origin.
The canonical should be absolute, use HTTPS in production, and include the exact guide slug. It must never inherit a preview deployment hostname or a local development address. Treat the site URL as required build configuration so a missing value stops the release rather than quietly publishing misleading metadata.
Keep discovery signals synchronized
Canonical tags work best when the rest of the site agrees. The gateway home page should link to the same guide paths, and the sitemap should contain the identical URL set. Related-guide links rendered by the origin should also use public prefixed paths, allowing them to remain on the gateway after the rewrite.
Validate the sets mechanically after each content change. Removing a slug requires removing its sitemap entry and every relationship that points to it. Adding a new domain requires rebuilding both projects so robots, sitemap, Open Graph URLs, and canonical tags all move together.