Canonical URLs

Learn what a canonical URL is, how m18t derives it from your brand, type, locale, and slug, how to override it for syndication, and what m18t leaves to you.

What you'll learn

  • What a canonical URL is and why duplicate content hurts ranking.
  • How m18t derives the canonical from your brand, type, locale, and slug.
  • How to override the canonical for syndicated content, and what m18t does not do for you.

The concept: one address is the master copy

A canonical URL is a tag in a page's <head> — <link rel="canonical" href="…" /> — that tells search engines which address is the original when the same content appears at more than one URL. Without it, syndicating an article to Medium or a partner site can split ranking signals across copies, and search engines may pick the wrong one to surface.

m18t's job is to compute the right canonical and put it in the metadata it pushes to your CMS. Because it's derived from structured inputs rather than typed by hand, the same kind of content produces the same URL shape every time. That predictability is the point — see The SEO Philosophy for why m18t leans on derivation over free text.

How m18t derives the canonical

When you create a piece, m18t builds the canonical from four inputs:

  1. The brand's website URL (set on the brand) — the domain, with any trailing slash stripped.
  2. The content type's path prefix (from Content Types) — e.g. /blog/. A root type (/) contributes no prefix.
  3. The locale — the piece's primary locale adds nothing; a non-primary locale prepends /{locale}.
  4. The slug — the piece's URL slug.

So a primary-locale blog post resolves to https://brand.example/blog/my-post, and its Arabic sibling (if Arabic isn't that brand's primary locale) resolves to https://brand.example/ar/blog/my-post. The canonical field is pre-filled when you create the piece; if you change the type or slug, click Re-derive from SEO index next to the field to recompute it.

This derived canonical is also handed to the SEO AI prompt. When the model drafts JSON-LD, it's instructed to use only that exact URL — which is how m18t keeps generated structured data from pointing at invented addresses.

Overriding for syndication

There's one case where the derived canonical is wrong on purpose: when you're re-publishing content that originated somewhere else, and you want to credit the original. Example — you reproduce a piece that first ran on another publication and want search engines to treat that publication as the source.

  1. Open the piece in the content editor and go to the SEO tab.
  2. In the Canonical URL field, replace the derived value with the original external URL (e.g. https://example.com/the-original-article).
  3. Save the piece.

When you push to your CMS, the metadata carries your override instead of the derived URL.

An honest limit: redirects are not m18t's job

If you change a published piece's slug, its canonical changes too — which breaks existing inbound links to the old URL. m18t updates the metadata, but it does not create the 301 redirect from the old address to the new one. That redirect lives in your front-end or web server (Nuxt, Next.js, Astro, a reverse proxy, etc.). Set it there so old links keep working.

Likewise, m18t emits the canonical into the payload it sends your CMS — it doesn't render your public pages. If the tag isn't showing up in the live HTML, the gap is on the rendering side. Walk it in SEO troubleshooting.

What's next

FAQ

How does m18t build the canonical URL? From the brand website URL + the content type's path prefix + a locale segment (only for non-primary locales) + the piece's slug. Change the type or slug and click Re-derive from SEO index to recompute.

Can I point the canonical at an external site? Yes. On the piece's SEO tab, replace the Canonical URL with the external original and save. The override is what gets pushed to your CMS.

I changed a slug and old links 404. Does m18t redirect? No. m18t updates the canonical metadata; the 301 redirect from old to new URL is configured in your front-end or web server, not in m18t.

Why doesn't the canonical tag appear on my live page? m18t pushes the canonical into the CMS payload; your front-end has to render it into the page <head>. If it's correct in m18t but absent in the HTML, the issue is rendering — see SEO troubleshooting.

Was this article helpful?