One Fact, One URL: Canonicals, Duplicate Content, Freshness and AI Search

When a business changes its address, the update may reach its homepage before its directories, PDFs and older landing pages. Search systems can then encounter conflicting information about the same business.

Imagine a move where the contact page and Google Business Profile are current, but a location page and an indexed brochure still list the former office. A reader looking for directions needs a clear current source and context for the historical material.

Our operating principle is to give each important fact an obvious home, then keep other current references aligned with it. This guide explains how that principle relates to canonical URLs, redirects and content ownership.

The web naturally creates duplicates

Duplicate and overlapping information appears through:

• tracking parameters,
• print versions,
• tag pages,
• category archives,
• old slugs,
• HTTP/HTTPS variants,
• www/non-www variants,
• faceted navigation,
• campaign landing pages,
• staging copies,
• migration leftovers,
• pagination,
• syndicated content,
• and content teams writing the same article again because nobody knew the first one existed.

Some duplication is harmless. Some makes canonical selection unnecessarily difficult. Bing’s current guidance is unusually direct. It says duplicate URLs can dilute signals and reduce confidence in selecting a URL for grounding results or citations.

That is exactly the AI-search implication we care about.

Canonicalization is a confidence problem

Canonical tags are signals. They help identify a preferred version.

But a strong canonical strategy uses multiple aligned signals:

• rel=canonical
• internal links
• sitemaps
• redirects where appropriate
• URL consistency
• content consolidation
• and external links when possible

If the canonical tag says:

Use /new-service/

while every internal link still points to:

/old-service/

the site is having an argument with itself. Machines notice contradictions. They may resolve them correctly. We prefer not to make the resolution harder.

One fact, one URL does not mean one fact only appears once

Important clarification.

Your phone number can appear on:

• the contact page,
• location page,
• footer,
• structured data,
• and business profiles.

That is fine.

“One fact, one URL” means there should be an obvious authoritative owner for details that need maintenance.

For example:

• Organization-level information → About or Contact
• Office-specific information → canonical location page
• Person credentials → canonical person profile
• Service details → canonical service page
• Policy → canonical policy page
• Pricing → canonical pricing page

Then supporting pages can reference those facts consistently. This creates governance. Not artificial scarcity.

Freshness is about truth, not dates

Freshness gets abused. Some sites update the “Published” date every year and change nothing else.

A useful freshness strategy asks:

• Did the fact change?
• Does the page still reflect current reality?
• Can systems detect the update?
• Should obsolete content be redirected, removed, or preserved historically?

Bing recommends accurate freshness signals such as lastmod and IndexNow where applicable. But no timestamp can rescue stale facts. You cannot freshness-markup your way out of being wrong.

Canonical tags are not a substitute for cleanup

A canonical tag can tell search engines which URL you prefer. It does not erase the duplicate page from existence.

If duplicate URLs:

• remain internally linked,
• remain in sitemaps,
• receive external links,
• stay indexable,
• and contain stale variations,

you still have technical debt. Fix duplication at the source where practical. Use canonicals as part of the solution.

When to redirect

If a page permanently moved and the old URL no longer has a reason to exist, redirect it. Bing recommends permanent redirects for permanent moves. This preserves a cleaner source path.

Examples:

• old attorney slug → new attorney slug
• old service URL → canonical service URL
• merged article → stronger canonical guide
• closed location → appropriate replacement or factual closure page depending on context

Do not leave obsolete pages alive just because “they have history.” History is not a technical requirement.

When to keep historical content

Some historical pages are valuable. Old research. Archived policies. Past events. Historical pricing. Press releases. The key is context. Mark the date clearly. Explain that the material is historical. Link to the current version where appropriate.

Do not let a 2022 page pretend to be the current answer.

Local businesses have a bigger consistency problem

Local entities exist in many places. Website. Google Business Profile. Bing Places. Directories. Maps. Professional profiles. Industry associations. Review platforms. Old citations. That means one fact can become distributed very quickly.

A location change can require updates across many systems. AI search makes this distributed identity more visible because answers may draw from multiple sources. The solution is not perfect uniformity everywhere forever.

The solution is disciplined source management and strong canonical first-party pages.

IndexNow is useful for the systems that support it

Bing recommends IndexNow for notifying it when URLs are:

• added,
• updated,
• or removed.

That can help Bing refresh its index and reduce outdated references in grounding systems. IndexNow is not a universal instant-index button. It is a notification mechanism supported by participating search engines.

Use it where it fits. Check which search engines support it and verify the resulting discovery separately.

Sitemaps should contain the pages you actually want

Bing recommends canonical URLs in XML sitemaps and accurate lastmod values.

Common sitemap problems:

• redirecting URLs
• 404s
• parameter variants
• noindex pages
• old staging URLs
• duplicate language versions
• obsolete content

If the sitemap is supposed to describe the canonical site inventory, make it honest.

The canonical URL should be the one you link to

This is one of the easiest improvements. Internal links should point directly to canonical destinations.

Avoid:

• links to redirects,
• links to parameter variants,
• links to old slugs,
• links to HTTP versions,
• links to duplicate campaign copies.

Every unnecessary hop is another contradiction between architecture and preference.