The SEO Philosophy

Why m18t sets SEO defaults per brand and content type instead of per piece, how it serves both search and answer engines, and how a piece overrides defaults.

What you'll learn

  • Why m18t sets SEO defaults per (brand × content type) instead of per piece.
  • The difference between optimizing for search engines and for answer engines.
  • Where those defaults live and how a single piece can override them.

The concept: defaults first, per-piece second

Most tools treat SEO as the last chore before publishing. You write the post, then open a plugin and fill in a meta title, a description, and a robots directive — from scratch, every time. With one writer that's tedious. With a team or an agency running several brands, it drifts: one post ends its title with a dash, the next with a pipe, a third forgets the brand name, and a fourth gets indexed when it shouldn't be.

m18t inverts the order. You decide the SEO shape of a kind of content once, and every new piece of that kind starts from those defaults. A blog post for one brand can carry a different URL prefix, schema.org type, robots policy, meta-title template, and fallback social image than a help article for another brand. The per-piece SEO panel is still there for the cases that genuinely differ — but the boring 90% is already filled in.

These defaults are attached to a content type, and content types are configured in one place. See Configuring SEO Defaults (in Content Types) for the field-by-field walkthrough. There is no separate "SEO" settings area to keep in sync — the defaults travel with the type.

Why per-(brand × type) is the right grain

A meta-title template like {{BRAND_TITLE}} | {{POST_TITLE}} only makes sense scoped to a brand: the brand name is the constant, the post title is the variable. A path prefix like /blog/ only makes sense scoped to a type: blog posts live under /blog/, help articles under /help/, landing pages at the root. Pin the default to both axes and it resolves cleanly for every new piece without anyone re-typing it.

This is also what makes canonical URLs deterministic. m18t builds a canonical from the brand's website URL, the type's path prefix, the locale, and the piece's slug. Because the prefix is a default on the type — not a free-text field a writer fills in — the URL comes out the same way for every piece of that type. That consistency is the whole point: predictable URLs, predictable titles, predictable structured data.

Search engines and answer engines want different things

m18t's SEO surface is built for two audiences, and they don't overlap as much as people assume.

  1. Search engines (Google, Bing) reward clean canonical URLs, a sensible robots policy, a meta title and description that match intent, and fast pages. This is the classic stuff: the canonical URL, the meta title template, the keywords field, the robots directives.

  2. Answer engines (LLM-backed tools like ChatGPT, Claude, and Perplexity) lean heavily on structured data — JSON-LD. They parse the explicit schema.org markup on a page to understand what an entity is before they cite it. A meta description doesn't help them much; a well-formed Article or FAQPage block does.

You don't have to choose. The same content type carries both: the schema.org @type that feeds answer engines and the title/robots/canonical defaults that feed search engines. Set the type up once and every piece is shaped for both channels.

What the defaults actually drive

When you create a piece and pick its type, the type's SEO defaults flow into:

  • The canonical URL, derived from the brand website + path prefix + locale + slug.
  • The meta title, pre-filled from the template (you can edit or regenerate it).
  • The robots directive (e.g. index, follow, or noindex, nofollow for an internal type).
  • The schema.org @type used when JSON-LD is generated.
  • A fallback OG image, used when a piece doesn't set its own social-share image.
  • The seed keywords the SEO AI prompt starts from.

None of these are locked. The per-piece SEO tab in the content editor overrides any of them when a specific post needs something different. The default is a starting point, not a cage.

An honest limit

m18t owns the metadata: it computes the canonical, fills the title, emits the JSON-LD, and pushes all of that to your CMS. It does not render your public website. If your front-end (Nuxt, Next.js, Astro, or whatever serves the brand site) doesn't read the SEO fields out of the CMS and put them in the page's <head>, the data is correct in m18t and invisible to Google. That last hop is your front-end's job — see SEO troubleshooting for how to tell which side is at fault.

What's next

FAQ

Where do I set SEO defaults in m18t? Inside Content Types, at /studio/config/content-types. Each type holds its own SEO defaults — path prefix, schema.org type, robots, meta-title template, fallback OG image, supported locales. There is no longer a standalone "SEO Indices" page; the old route 301-redirects to Content Types.

Can a single post override the brand-level defaults? Yes. Every piece has an SEO tab in the content editor. Anything you set there — meta title, description, canonical, robots, OG image, JSON-LD — overrides the type default for that piece only.

Does m18t optimize for AI answer engines or just Google? Both. The same content type carries the schema.org @type that answer engines parse and the title/robots/canonical defaults that search engines use. See Structured Data & JSON-LD.

Why aren't my meta tags showing on my live site even though they're correct in m18t? m18t produces and pushes the metadata; your front-end has to render it into the page <head>. That rendering is outside m18t. Walk the chain in SEO troubleshooting.

Was this article helpful?