Canonical URLs in Yoast SEO

How Yoast SEO handles canonicals by default

Where WordPress core only self-canonicalizes singular content, Yoast SEO extends that behavior to essentially every indexable page type on the site: single posts and pages, the homepage, category, tag, and other taxonomy archives, custom post type archives, author and date archives, and each individual paginated page within a series. In practice, this closes the gap left by core — Yoast is doing the work that plain WordPress doesn't.

There is one deliberate exception. A page or post that's set to noindex gets no canonical tag from Yoast at all. This trips people up regularly: they notice a page is missing its canonical, assume something is broken, and don't realize the page is noindexed and therefore not meant to have one in the first place. If you're troubleshooting a missing-canonical report, check the page's indexability setting before you check anything else.

Yoast doesn't add its canonical alongside WordPress core's default — it removes core's rel_canonical hook and replaces it with its own output. A correctly functioning Yoast install should produce exactly one canonical tag per page. If you find two, the cause is almost always a second plugin or theme code also trying to manage canonicals.

Where to set a canonical override in Yoast

Every self-referencing default Yoast generates can be overridden on a per-post, per-page, or per-term basis. In the classic Yoast metabox below the content editor, or in the Yoast sidebar panel in the block editor, open the Advanced section. There you'll find a field labeled Canonical URL.

In the block editor specifically, you can reach this either through the Yoast sidebar panel's Advanced section, or through the metabox's Advanced tab (the gear icon). Whichever path you use, the field expects a full, absolute URL — including the scheme (https://) and host (the domain), not a relative path. Leaving the field empty restores Yoast's default self-referencing behavior; you don't need to re-enter the page's own URL to reset it.

One administrative detail worth knowing: the Advanced section, including this field, can be hidden from non-administrator user roles. If an editor on your team says they can't find the canonical field, that's often a permissions setting rather than a bug.

Behind the scenes, the URLs Yoast uses are derived from its own indexables table (wp_yoast_indexable) combined with the WordPress Site Address configured under Settings → General. That detail matters directly for the troubleshooting section below.

Fixing a wrong Yoast canonical URL

The single most common cause of a wrong Yoast canonical is staging-domain leakage after a site migration. Here's how it happens: Yoast's indexables are built and cached using whatever domain was active at the time — often a staging URL like staging.example.com. When the database is copied over to the live domain during migration, those indexable records travel with it, still pointing at the old staging address. The result is a live site whose canonical tags reference a domain that doesn't even resolve publicly.

The fix has three steps, and skipping any one of them leaves the problem partially unsolved: first, run a proper search-and-replace across the database to swap the old domain for the new one. Second, rebuild the indexables — either through SEO → Tools → Start SEO data optimization in the Yoast admin, the Yoast Test Helper plugin's Reset Indexables option, or the WP-CLI command wp yoast index. Third, clear any caching layer (page cache, object cache, CDN) so visitors and crawlers aren't served a stale, pre-fix version of the page. Rebuilding the indexables without first fixing the underlying domain string in the database will simply regenerate the same wrong URLs.

A related but distinct cause is a scheme or subdomain mismatch — canonicals pointing to http:// when the site now serves https://, or to the non-www version when the site standardized on www (or vice versa). This traces back to the Site Address setting under Settings → General, or to a reverse proxy that isn't correctly passing HTTPS signals back to WordPress. Fix the site address (or HTTPS detection), then rebuild indexables the same way.

If a canonical seems stuck pointing at the homepage or at an ugly query-string URL like ?p=123, that's usually a stale-indexable or permalink issue — flushing permalinks and rebuilding indexables typically resolves it. And if a canonical simply isn't reflecting a recent change you made, check caching before anything else; a stale cache is the most likely explanation.

One more scenario worth flagging if you run a multilingual site with WPML or Polylang: each translation is meant to self-canonicalize to its own language-specific URL. Misconfiguration between the translation plugin and Yoast can cause translated pages to canonicalize back to the default-language URL, which effectively tells search engines to deindex the translation. Use the official glue or add-on plugin connecting Yoast to your multilingual plugin rather than relying on defaults alone.

The wpseo_canonical filter

For programmatic control beyond the per-page field, Yoast exposes a wpseo_canonical filter. This lets you override the canonical URL for specific conditions in code — useful when you need to apply a rule across many pages rather than editing each one by hand:

add_filter('wpseo_canonical', function($c) {
  if (is_page(12345)) $c = 'https://example.com/preferred-url/';
  return $c;
});

You can also use the same filter to suppress the canonical tag entirely on a given page by returning false:

add_filter('wpseo_canonical', '__return_false');

Use that second pattern carefully — removing the canonical tag outright is different from setting a page to noindex, and it should be a deliberate choice, not a default habit.

Common Yoast canonical mistakes

Three patterns account for most Yoast canonical problems in the wild.

• Pasting a canonical URL into the wrong post's Advanced field. Because the field is easy to copy-paste into, a single misapplied URL can accidentally point one post — or, through careless bulk editing, many posts — at someone else's canonical target, effectively deindexing everything that now defers to it. Always confirm you're editing the post you intend to before saving that field.
• Setting a canonical on a page that's also set to noindex, then wondering why no canonical tag appears. As covered above, Yoast deliberately withholds the canonical tag on noindexed pages. This isn't a bug to fix — it's expected behavior once you understand the noindex exception.
• Running two SEO plugins at once. If Yoast and a second SEO plugin (or a theme with its own canonical logic) are both active and both trying to manage the canonical tag, you can end up with duplicate or conflicting canonical tags on the same page. Only one plugin should be responsible for canonical output at a time.

Frequently Asked Questions