Design canonicals, sitemaps, and redirects

Give each useful page one durable address

URL consistency compounds. Choose lowercase, readable slugs; define trailing-slash and host rules; remove unnecessary tracking parameters from canonical destinations; and keep public URLs stable when copy or design changes.

A canonical is a hint about the preferred representative among duplicates. Reinforce it with redirects, internal links, sitemap entries, and consistent metadata. Do not canonicalize unrelated pages to a popular page, and do not expect a canonical to replace an information architecture.

Build a truthful sitemap

Include canonical, indexable, successful URLs you actually want discovered. Exclude redirects, errors, noindex pages, duplicate parameters, private app routes, and drafts. Use a meaningful last-modified timestamp only when the primary content changed—not every deployment or request. Split large sitemaps and expose the index in robots.txt.

Sitemaps aid discovery; they do not guarantee indexing. If a page is absent from navigation and weak in value, a sitemap entry does not repair those problems.

Redirect migrations as a mapping problem

Before a migration, export old URLs and map each to the closest useful successor. Use a permanent server-side redirect, avoid chains, update internal links and canonicals to the destination, and preserve high-value query behavior where appropriate. Return 404 or 410 when there is no replacement instead of sending every retired URL to the homepage.

After launch, monitor old URLs, redirect errors, canonical selection, sitemap processing, and landing-page performance. Keep redirects long enough for users, external links, and crawlers to adopt the new location.

Keep generated files reviewable

Generated robots.txt, sitemap.xml, and llms.txt outputs should state what was observed and what was excluded. Validate syntax and URLs. A generated file is a proposal to review, not authority to overwrite production policy blindly.