Ghost SEO

TL;DR — Ghost is a publishing platform that, in its normal mode, does most of your technical SEO for you automatically — sitemap, canonical tags, meta tags, social cards, structured data — with no plugin to install. It’s also fast out of the box. The big catch: if you run Ghost “headless” (just as a content source for a separate website), all of that built-in SEO goes away and a developer has to rebuild it. And members-only content can’t show up in Google at all.

What Ghost is

Ghost is a content management system — like WordPress, but built specifically for blogs, newsletters, and paid memberships rather than for every kind of website. You write posts in Ghost, and Ghost publishes them.

The thing that makes Ghost different for SEO is that it can run in two completely different ways:

• The normal way (traditional mode). Ghost runs your whole site — it stores your content and turns it into web pages. This is what most people use.
• The headless way. Ghost becomes just a storage box for content. A separate website (built by a developer with something like Next.js or Astro) pulls the content out and builds the pages itself.

This choice changes everything about Ghost’s SEO, so keep it in the back of your mind.

What Ghost does for you automatically (normal mode)

If you run Ghost the normal way, it quietly handles the technical SEO basics with no setup:

• A sitemap — an auto-updating list of your pages at yourdomain.com/sitemap.xml that you can hand to Google and Bing. Evidence for this claim Traditional Ghost includes automatic SEO features including XML sitemaps, canonical tags, metadata, and structured data. Scope: Ghost-rendered sites using supported themes; headless frontends must implement their own output. Confidence: high · Verified: 2026-07-14 Ghost: SEO
• Canonical tags — these tell search engines which version of a page is the “official” one, so duplicate pages don’t compete.
• Meta titles and descriptions — with sensible fallbacks if you leave them blank.
• Social cards — Open Graph and Twitter Card tags so links look good when shared.
• Structured data — the behind-the-scenes Article markup that helps search engines understand your post.
• Clean URLs and a fast site by default.

In WordPress you’d install a plugin like Yoast to get most of this. In Ghost it’s just there.

What Ghost doesn’t do

Ghost covers the core, not the extras. It won’t add breadcrumb or FAQ structured data, it has no built-in support for multi-language (hreflang) sites, no per-post “hide from Google” toggle in the menu, and no Yoast-style keyword checklist. Those need code or a third-party tool.

The one thing people get wrong

Members-only content can’t rank. If you put a post behind a paid (or free email) membership, Google literally can’t read it — Ghost hides it from everyone who isn’t logged in, search engines included. The fix is to publish a public preview or teaser that can rank, and use the gated part to convert readers into subscribers. Don’t expect locked posts to bring in search traffic.

Want the full version — the traditional-vs-headless decision, the headless rebuild checklist, gated-content schema, and Ghost Pro vs self-hosted? Switch to the Advanced tab.

TL;DR — Ghost SEO forks on one decision: traditional (Handlebars) mode vs. headless (Content API). Traditional Ghost ships core technical SEO automatically — sitemap, self-referencing + custom canonicals, meta tags, OG/Twitter cards, and Article JSON-LD — with no plugin, and it’s fast by default. Go headless and all of that disappears; the frontend has to rebuild every piece, and Ghost’s speed advantage evaporates because the framework now owns performance. Both modes share gaps Ghost never fills (breadcrumb/FAQ/Product schema, hreflang, per-post noindex, IndexNow, a redirect UI), and gated members-only content is blocked server-side so it can’t be indexed. Don’t conflate the two modes — they’re different problems.

The fork in the road

Ghost is a Node.js (Express) CMS with a decoupled core: an API plus an optional Handlebars frontend. That architecture is the whole SEO story.

• Traditional mode — Ghost serves HTML through its Handlebars themes. Every built-in SEO feature applies, generated automatically via the theme’s {{ghost_head}} helper.
• Headless mode — Ghost is “a full headless CMS which is completely agnostic of any particular front end or static site framework.” You query the Content API or Admin API from a separate frontend (Next.js, Astro, Nuxt, SvelteKit), and SEO becomes 100% that frontend’s responsibility.

The choice of mode is the single biggest determinant of Ghost’s SEO footprint. Everything below is organized around it. (For the framework-agnostic version of the headless side, see SEO for a Headless CMS.)

What traditional Ghost handles automatically

In traditional mode Ghost does the core technical SEO with zero configuration:

• Sitemap. Auto-generated at /sitemap.xml, updated on publish/unpublish, covering posts, pages, tags, and authors. “Ghost automatically creates and updates an XML sitemap for your website.” Evidence for this claim Ghost automatically creates and updates an XML sitemap. Scope: Traditional Ghost publication output. Confidence: high · Verified: 2026-07-14 Ghost: SEO
• Canonical tags. A self-referencing rel=canonical on every post and page — “Ghost adds canonical tags across your site to tell search engines which version of a page they should consider the ‘official’ one.” Since March 2019 you can also set a custom canonical per post in the editor’s metadata panel, or via the Admin API canonical_url field — built for “guest posts, multiple versions of the same page or when you need to curate a list of links to external sources.” Evidence for this claim Ghost outputs canonical tags and supports a custom canonical URL for a post or page. Scope: Traditional Ghost and the post/page metadata configuration. Confidence: high · Verified: 2026-07-14 Ghost: Canonical URLs
• Meta title/description. Custom fields that fall back to the post title and excerpt when left blank.
• Open Graph + Twitter Cards. Auto-generated from post metadata and the feature image.
• Structured data (JSON-LD). “Ghost automatically includes structured data in all posts and pages” — Article schema with publisher, author, headline, datePublished, dateModified, image, and keywords.
• Clean URLs + custom routing. Slug-based URLs by default, fully customizable via routes.yaml.
• robots.txt. A default file that disallows the /ghost/ admin path and allows everything else.

This is genuinely more than a stock WordPress install gives you — Ghost lists “XML sitemaps, canonical tags, optimised URLs, microformats, Facebook Open Graph tags, support for Twitter cards and clean semantic markup” as built-in, no plugin required.

What Ghost never does — in either mode

Ghost covers the core and stops there. It does not generate:

• Advanced schema — breadcrumb, FAQ, HowTo, Product, Recipe, or Video markup. Article schema only. Anything else is manual code injection or theme work.
• Hreflang / international SEO — no native support. Multi-language Ghost needs a third-party service (Weglot, ConveyThis) or theme-level implementation, and hreflang is notoriously error-prone.
• A per-post noindex toggle in the UI — you need code injection.
• Keyword optimization guidance. This is deliberate. Asked about adding Yoast-style tools, the Ghost team argued that “one of the downsides of using Yoast’s KW optimisation suggestions is that is encourages us to write meta data for machines instead of humans,” and on the broader advanced-SEO wishlist (breadcrumb schema, hreflang, noindex controls) said flatly: “This isn’t on our radar at the moment.”
• IndexNow — no native support; wire it via a custom webhook on publish if you want Bing/others notified instantly.
• A redirect-management UI — redirects live in redirects.yaml (self-hosted) or Ghost Pro’s redirect manager; there’s no plugin ecosystem to lean on.

Headless Ghost: the SEO you have to rebuild

Go headless and Ghost stops being an SEO system — it’s a content API. Everything in the “handles automatically” list above is now the frontend’s job:

• Sitemap — generated at build time or by a serverless function hitting the Content API.
• Canonical tags — injected by the frontend framework, ideally absolute URLs from one SITE_URL.
• Meta + OG/Twitter tags — rendered via the framework’s head management (Next.js generateMetadata, Astro’s <head>, Nuxt useSeoMeta).
• Structured data (JSON-LD) — now entirely custom.
• robots.txt — served by the frontend.
• 301/302 redirects — handled in the frontend or the CDN layer.
• Core Web Vitals — Ghost’s speed advantage disappears; the framework and rendering mode now dominate performance.

The one thing that carries over: the Content API still returns the editorial metadata you typed into Ghost’s editor — meta_title, meta_description, og_title, og_description, og_image, twitter_title, twitter_description, twitter_image, and canonical_url. The data is available; rendering it is on you. This is the headless-CMS SEO problem in general, and it’s really a JavaScript SEO problem — if your frontend defaults to client-side rendering, Googlebot has to queue the page for a later render wave. AI-crawler rendering varies by provider, so render on the server or at build time (SSR/SSG) to maximize coverage.

Gated content and what Google can see

Ghost supports three visibility levels: public, members-free (email required), and members-paid (subscription). The crucial point for SEO is that gated content is blocked server-side, not by sniffing the user agent. As Ghost’s own team put it: “Google can’t crawl protected content on your page, because that’s only ever available to logged in members.” Google gets exactly the same restricted view a logged-out reader gets.

Two realistic strategies:

1. Public preview. Show an intro / first few paragraphs publicly and gate the rest. Ghost has a native public-preview feature for this — the public portion does the ranking work.
2. Metered access. Third-party implementations allow N free articles before requiring registration.

If you do gate content, Google supports paywalled markup — NewsArticle with isAccessibleForFree: false and a hasPart/cssSelector describing the gated region — but Ghost doesn’t generate this automatically; it’s manual code injection. And the hard rule either way: don’t cloak. Showing Googlebot the full article while readers hit a paywall violates Google’s guidelines and risks a manual action. The honest framing is that public content ranks and gated content converts — don’t expect locked posts to bring search traffic.

Ghost Pro vs self-hosted

The SEO software is identical on both — same Ghost, same features. The difference is infrastructure control:

• Ghost Pro — managed hosting with a built-in CDN, automatic SSL, and backups. The CDN helps TTFB and Core Web Vitals for distributed audiences. The catch: you can’t directly override robots.txt — you have to contact support. That’s a real constraint for headless or private-mode setups.
• Self-hosted — full control of the server, headers, caching, robots.txt, server-level redirects, and your own CDN (Cloudflare is the common pick). More flexibility for advanced technical SEO, more to manage.

Neither is “better for SEO” inherently — Ghost Pro buys you a CDN, self-hosting buys you control.

Common pitfalls

• Thin tag/author archives. Ghost auto-creates /tag/slug/ and /author/slug/ pages. Granular tags or single-post authors generate thin pages — consider noindexing the low-value ones.
• Preview-URL indexing. Older Ghost versions could leak draft preview URLs to Googlebot via third-party scripts loading on preview pages (since fixed in core — see GitHub issue #9749). Verify preview pages aren’t indexed on older installs.
• /ghost/ accidentally exposed. Confirm the default robots.txt disallow on the admin path hasn’t been overridden.
• Duplicate content from custom collections. routes.yaml collections can create alternate URL paths for the same content. Ghost canonicalizes its default structure; custom routing can create duplicates if you don’t manage canonicals explicitly.
• Missing custom canonical on syndicated/guest posts. If you republish content from elsewhere, set canonical_url per post (editor or API) to point at the original — the feature only exists since March 2019.
• Headless pre-launch indexing. A public headless frontend deployed before launch without its own robots.txt can get indexed prematurely. Ghost’s own “private” mode sends Disallow: /, but that protects the Ghost instance, not your separate frontend.

Ghost vs WordPress, briefly

Ghost gives you more SEO out of the box with zero configuration and is faster by default (Ghost’s own benchmark claims it’s “up to 1,900% faster than WordPress” — treat that as a vendor figure, but the direction is real: minimal JS, strong CWV baseline). WordPress’s ceiling is higher with the right plugins — schema, redirect managers, programmatic SEO — but its plugin-heavy norm often hurts performance. Ghost suits publishers who want to write without SEO-plugin overhead; WordPress suits complex sites needing advanced schema or large integrations. “Faster, therefore ranks better” is an oversimplification — Core Web Vitals is one factor among many, and headless Ghost’s speed depends entirely on the frontend, not Ghost.

AI summary

A condensed take on the Advanced version:

• Ghost SEO forks on one decision: traditional (Handlebars) mode vs. headless (Content API). The mode is the single biggest determinant of Ghost’s SEO footprint.
• Traditional Ghost ships core SEO automatically, no plugin: sitemap at /sitemap.xml, self-referencing canonicals (+ custom canonical per post since March 2019), meta title/description with fallbacks, OG/Twitter cards, Article JSON-LD, clean URLs, and a robots.txt that disallows /ghost/. It’s also fast by default.
• Headless Ghost loses all of it. The Content API still returns the metadata fields, but the frontend must rebuild sitemap, canonicals, meta tags, structured data, robots.txt, redirects — and Ghost’s speed advantage disappears. Render SSR/SSG, not CSR (AI-crawler rendering support varies by provider).
• Gaps in both modes: no breadcrumb/FAQ/Product schema, no hreflang, no per-post noindex toggle, no IndexNow, no redirect UI. Some are deliberate — Ghost rejects Yoast-style keyword tools as “writing for machines.”
• Gated content can’t be indexed — it’s blocked server-side, so Google sees what a logged-out reader sees. Use a public preview to rank; gate the rest to convert. Don’t cloak.
• Ghost Pro vs self-hosted: identical SEO features; Pro adds a CDN but locks robots.txt behind support; self-hosting gives full control.
• Pitfalls: thin tag/author archives, preview-URL indexing on old versions, duplicate content from custom routes.yaml collections, missing custom canonicals on syndicated posts.

Official documentation

Primary-source documentation from the search engines and from Ghost itself.

Google

• Understand JavaScript SEO Basics — applies directly to headless Ghost: the crawl → render → index pipeline and why CSR content is seen late.
• Enable Subscription and Paywalled Content — NewsArticle + isAccessibleForFree + hasPart/cssSelector for gated content.
• Block Search Indexing with noindex — the noindex meta tag and X-Robots-Tag header for previews and the admin path.
• Sitemaps Overview — what to submit; Ghost auto-generates one in traditional mode.

Bing / Microsoft

• Bing Webmaster Tools — Submit Sitemaps — submit Ghost’s /sitemap.xml directly.
• IndexNow / indexnow.org — the push protocol Ghost has no native support for; wire it to a publish webhook.

Ghost (official)

• Ghost Help — SEO — the canonical list of what Ghost handles automatically.
• Ghost Developer Docs — Architecture — Ghost as a headless CMS, agnostic of any frontend.
• Ghost Docs — URLs & Routing — routes.yaml, collections, and custom URL structure.
• Ghost Changelog — Custom Canonical URLs — the March 2019 per-post canonical feature.
• Ghost Resources — SEO for Membership Websites — Ghost’s own take on gated-content SEO.

Quotes from the source

On-the-record statements from Ghost’s docs and team. Each link is a deep link that jumps to the quoted passage on the source page.

Ghost — built-in SEO features

• “Ghost automatically creates and updates an XML sitemap for your website to help search engines understand the structure of your site and find all of its content.” — Ghost Help Docs. Jump to quote
• “Ghost adds canonical tags across your site to tell search engines which version of a page they should consider the ‘official’ one. This helps prevent problems with duplicate content.” — Ghost Help Docs. Jump to quote
• “Ghost automatically includes structured data in all posts and pages. This helps search engines understand the content and context of your pages.” — Ghost Help Docs. Jump to quote

Ghost — headless architecture

• “Ghost is a full headless CMS which is completely agnostic of any particular front end or static site framework.” — Ghost Developer Docs. Jump to quote

Ghost — gated content and crawling

• “Google can’t crawl protected content on your page, because that’s only ever available to logged in members.” — Kym, Ghost team, Ghost Forum. Jump to quote

Ghost — custom canonical URLs (March 2019)

• The feature lets you “implement custom canonical links directly in the Ghost editor for guest posts, multiple versions of the same page or when you need to curate a list of links to external sources.” — Ghost Changelog. Jump to quote

Ghost — on advanced SEO features (team response)

• “one of the downsides of using Yoast’s KW optimisation suggestions is that is encourages us to write meta data for machines instead of humans.” — Ghost team, Ghost Forum. Jump to quote
• On a wishlist of advanced SEO features (breadcrumb schema, hreflang, noindex controls): “This isn’t on our radar at the moment.” — Ghost team, Ghost Forum. Jump to quote

Ghost — performance (vendor benchmark)

• “Independent tests have found Ghost to be up to 1,900% faster than WordPress.” — Ghost vs WordPress page. Jump to quote

Two checklists: traditional Ghost + headless Ghost

Traditional Ghost — verify post-launch

• /sitemap.xml resolves and is submitted to Google Search Console and Bing Webmaster Tools.
• robots.txt still disallows /ghost/ and isn’t blocking anything you want indexed.
• Canonical tags render on posts/pages; syndicated or guest posts have a custom canonical_url set.
• Meta titles/descriptions are set (or the title/excerpt fallbacks are acceptable).
• OG/Twitter cards preview correctly when a post is shared.
• Article JSON-LD validates in the Rich Results Test.
• Thin /tag/ and /author/ archives are reviewed — noindex the low-value ones.
• Members-only posts have a public preview if you want them to attract search traffic.
• Any advanced schema you need (breadcrumb, FAQ, Product) is added via code injection — Ghost won’t generate it.

Headless Ghost — full implementation checklist

• Frontend renders content as SSR or SSG, not CSR (raw HTML maximizes AI-crawler coverage).
• Sitemap generated from the Content API and kept fresh.
• Canonical tags rendered as absolute URLs from one SITE_URL at the rendering layer.
• Meta title/description/OG/Twitter pulled from the Content API fields and mapped into the <head>.
• JSON-LD structured data rebuilt in the frontend.
• robots.txt served by the frontend and does not block .js/.css.
• 301/302 redirects handled in the frontend or CDN layer.
• Preview/branch deploys return a host-level noindex header.
• Core Web Vitals measured — Ghost’s speed advantage is gone; the framework owns it now.
• IndexNow wired to the publish webhook for Bing and others.

The mental models

1. The mode is the product. Before any Ghost SEO conversation, answer one question: is this traditional or headless? Traditional Ghost is a near-complete SEO system. Headless Ghost is a bare content API. Almost every Ghost SEO question resolves to which one you’re on.

2. “Headless means rebuild everything.” Every automatic traditional-mode behavior — sitemap, canonicals, meta tags, OG cards, JSON-LD, robots.txt — is now a deliberate build step in your frontend. The Content API hands you the data; rendering it is on you. If something’s “missing” in a headless build, it usually means a built-in behavior was never re-implemented.

3. Ghost covers the core, not the extras. In both modes, Ghost gives you Article schema and stops. Breadcrumb, FAQ, HowTo, Product, hreflang, per-post noindex, IndexNow — none are built in. Plan for code injection or third-party tools if your niche needs them.

4. Public ranks, gated converts. Members-only content is invisible to search engines by design. Don’t fight it — use a public preview to do the ranking and the gate to do the converting. Never cloak to show Google more than readers see.

5. Pro vs self-hosted is an infrastructure decision, not an SEO-feature one. The SEO software is identical. Choose on control: Ghost Pro gives you a CDN but locks robots.txt; self-hosting gives you full server control and your own CDN.

Ghost SEO — cheat sheet

Traditional vs headless: what you get

Never built in (either mode)

• Breadcrumb / FAQ / HowTo / Product / Recipe / Video schema → code injection
• Hreflang / international SEO → Weglot, ConveyThis, or theme work
• Per-post noindex toggle → code injection
• IndexNow → custom webhook on publish
• Redirect UI → redirects.yaml (self-hosted) or Ghost Pro’s manager

Gated content rules

• Members-only content is blocked server-side → not indexable.
• Use the public preview feature to expose a rankable teaser.
• Paywalled schema (NewsArticle + isAccessibleForFree: false) is not auto — code injection.
• Never cloak (full content to Googlebot, paywall to users) → manual-action risk.

Pro vs self-hosted

• Same SEO features on both.
• Ghost Pro: CDN included; robots.txt change requires contacting support.
• Self-hosted: full control of robots.txt, headers, redirects, your own CDN.

Sample Ghost posts from the sitemap

Download the relevant sitemap first, extract a representative URL list to urls.txt, then inspect what the theme or headless frontend publishes:

while IFS= read -r url; do
  html=$(mktemp)
  status=$(curl -sSL -o "$html" -w '%{http_code}' "$url")
  canonical=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | head -1)
  robots=$(grep -Eio '<meta[^>]+name=["'"']robots["'"'][^>]*>' "$html" | head -1)
  printf '%s\t%s\t%s\t%s\n' "$status" "$url" "$canonical" "$robots"
  rm -f "$html"
done < urls.txt

Include public, gated, tag, author, and recently redirected examples. This checks the public output without putting a Ghost Content API key into the script.

Tools for Ghost SEO

• URL Inspection (Google Search Console) — see how a Ghost page was crawled and rendered. Essential on headless builds for catching CSR gaps where content didn’t make it into the rendered HTML.
• Rich Results Test — confirm Ghost’s auto Article JSON-LD (traditional) or your custom JSON-LD (headless) is present and valid after any theme or rendering change.
• Bing Webmaster Tools — submit Ghost’s sitemap, watch indexing, and where IndexNow submissions land.
• Screaming Frog SEO Spider — crawl the site to surface thin tag/author archives, redirect chains, and (on headless) raw-vs-rendered HTML differences.
• Ahrefs Site Audit — surfaces broken canonicals, missing metadata, and indexability issues across the whole site; useful for spotting duplicate content from custom routes.yaml collections.
• Ghost editor metadata panel — the per-post place to set custom title, description, OG/Twitter overrides, and the custom canonical URL.

Ghost SEO mistakes to avoid

Concrete mistakes people actually make running Ghost — prevention, not diagnosis.

Treating traditional and headless Ghost as the same SEO problem. Why it’s wrong: traditional Ghost ships a sitemap, canonicals, meta tags, OG/Twitter cards, and Article JSON-LD automatically; headless Ghost is a bare content API with none of that. Advice written for one mode is often actively wrong for the other. What to do instead: before touching anything, confirm which mode you’re on, then follow the matching checklist above.

Expecting members-only content to bring in search traffic. Why it’s wrong: Ghost blocks gated content server-side, so Google gets exactly the same restricted view a logged-out visitor gets — there’s no content to index. What to do instead: publish a public preview or teaser using Ghost’s native public-preview feature and let that piece do the ranking work; use the gate to convert readers who arrive through it.

Cloaking to work around the gate. Why it’s wrong: showing Googlebot the full article while readers hit a paywall violates Google’s guidelines and risks a manual action — it’s not a clever workaround, it’s a policy violation. What to do instead: if you need gated content to be discoverable, use Google’s paywalled-content markup (NewsArticle with isAccessibleForFree: false and a hasPart/cssSelector for the gated region) — added via code injection, since Ghost doesn’t generate it — rather than serving different HTML to the crawler.

Republishing or guest-posting content without setting a custom canonical. Why it’s wrong: Ghost’s default canonical is self-referencing, so a syndicated or guest post left as-is tells search engines it is the original, competing with the source. What to do instead: set the per-post canonical_url in the editor’s metadata panel (or via the Admin API) to point at the original — the feature has existed since March 2019.

Shipping a headless frontend that renders content client-side. Why it’s wrong: Googlebot has to queue CSR pages for a later render pass, while AI-crawler rendering contracts vary by provider — content that only exists after a client-side fetch can be invisible to HTML-only fetchers. What to do instead: render on the server or at build time (SSR/SSG) in whatever framework pulls from the Content API, and verify with GSC’s URL Inspection tool that the rendered HTML actually contains the content.

Assuming Ghost Pro gives you the same infrastructure control as self-hosting. Why it’s wrong: the SEO software is identical on both, but Ghost Pro doesn’t let you directly edit robots.txt — you have to contact support, which is a real constraint if you need a fast robots.txt change for a headless or private-mode setup. What to do instead: factor that support-ticket lag into any launch plan on Ghost Pro, or self-host if you need to change robots.txt yourself on short notice.

Which Ghost SEO path applies to you?

The branch that matters most is traditional vs. headless — and, inside headless, whether the frontend renders server-side. Answer honestly; the wrong branch leads to work that doesn’t apply to your setup.

Ready-to-copy prompts for Ghost SEO tasks

Paste the specified input into an AI assistant and check the output against the guidance above before acting on it.

1. Audit a headless Ghost frontend for missing SEO fields. What to paste in: the rendered HTML of one page from your headless frontend (view source or the DOM after JS runs), plus the Content API response for that same post.

I'm running Ghost as a headless CMS. Here is the Content API response for a post,
followed by the final rendered HTML of that post's page on my frontend.

[paste Content API JSON response]

[paste rendered HTML]

Compare them and tell me which of these are present in the rendered HTML and
correctly populated from the API data: canonical tag, meta title, meta description,
Open Graph tags, Twitter Card tags, and Article JSON-LD structured data. List
anything missing or mismatched.

What to expect back: a field-by-field checklist flagging any of the six items that are absent from the rendered HTML or don’t match the API’s meta_title, canonical_url, etc. — confirm any flagged gap manually before fixing it.

2. Draft Article JSON-LD for a headless Ghost post. What to paste in: the Content API fields for one post (title, excerpt, published date, updated date, author, feature image URL, canonical URL).

Using this Ghost Content API data for a blog post, write valid Article JSON-LD
structured data I can inject into my headless frontend's <head>. Include
headline, datePublished, dateModified, author, publisher, and image.

[paste post JSON: title, excerpt, published_at, updated_at, primary_author, feature_image, canonical_url]

What to expect back: a single <script type="application/ld+json"> block — validate it in Google’s Rich Results Test before shipping, since the model can mis-map a field or omit a required property.

3. Check a syndicated/guest post for a missing custom canonical. What to paste in: the post’s slug, its canonical_url field (or “not set”), and the URL of the original source it was republished from.

This is a guest post or syndicated republish on my Ghost site. Here's the post
slug, its current canonical_url setting, and the URL of the original source.

Slug: [slug]
Current canonical_url: [value or "not set"]
Original source URL: [URL]

Tell me whether the canonical is set correctly to point at the original, and if
not, what canonical_url value I should set in the Ghost editor's metadata panel.

What to expect back: a yes/no on whether the canonical is correct, plus the exact URL to paste into the custom canonical field if it isn’t.

Test yourself: Ghost SEO

Five quick questions on how SEO works on Ghost CMS. Pick an answer for each, then check.

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — where platform and CMS SEO fit in the bigger picture.
• JavaScript SEO Issues & Best Practices — the rendering side that headless Ghost turns into; rendering modes, metadata, JS canonicals, and the robots.txt .js/.css rule.
• Robots.txt and SEO: Everything You Need to Know — relevant to Ghost’s default /ghost/ disallow and the Ghost Pro robots.txt constraint.

My speaking

• How Search Works (SlideShare) — crawling, rendering, indexing, and ranking — the pipeline gated and headless Ghost content has to survive. (Standing disclaimer: “This is my understanding of systems… not going to be 100% complete or accurate.”)

From around the industry

• Ghost Help — SEO — Ghost’s own list of what it handles automatically; the canonical primary source.
• Ghost Developer Docs — Architecture — Ghost as a headless CMS and how the decoupled API/frontend split works.
• Using Ghost as a Headless CMS with Next.js (Draft.dev) — a concrete walkthrough of the headless setup whose SEO you’d have to rebuild.
• Ghost Blog SEO: my experiences and results (Norbert Hires) — a practitioner’s first-party data and honest limitations from running Ghost.
• Schema markup in Ghost (Bright Themes) — how to add the advanced schema Ghost doesn’t generate.
• Breadcrumbs in Ghost (Bright Themes) — implementing breadcrumb schema Ghost leaves out.
• Taking Control of Structured Data in Ghost (ashryan.io) — overriding and extending Ghost’s default JSON-LD.
• r/TechSEO — the community for crawl/index/render debugging that headless Ghost questions land in.

Ghost SEO

Ghost SEO is the practice of optimizing a site built on Ghost CMS. The work splits in two: in traditional (Handlebars) mode Ghost handles core technical SEO automatically; run headless and you must rebuild all of it in the frontend.

Related: Headless CMS SEO, JavaScript SEO

Ghost SEO

Ghost is an open-source, Node.js content management system built for professional publishing. Its SEO story splits cleanly along one axis: how you run it.

In traditional mode — Ghost serving its own Handlebars-based frontend — most technical SEO is built in and requires no plugin. Ghost auto-generates an XML sitemap at /sitemap.xml, adds a self-referencing canonical tag to every page (with a per-post custom-canonical override since March 2019), produces meta titles/descriptions, Open Graph and Twitter Card tags, and Article JSON-LD structured data. URLs are clean and slug-based, and the default robots.txt disallows the /ghost/ admin path. Ghost is also fast by default — minimal JavaScript and good Core Web Vitals out of the box.

In headless mode — Ghost used purely as a content backend via the Content API or Admin API, with a decoupled frontend like Next.js, Astro, or Nuxt — all of those built-in features go away. The sitemap, canonicals, meta tags, structured data, and robots.txt become the frontend developer’s job to rebuild. The Content API does return the editorial metadata fields (meta_title, meta_description, og_*, twitter_*, canonical_url), but the frontend has to render them.

The biggest mistake in Ghost SEO is conflating the two modes — they are completely different problems. A separate constraint applies to both: members-only (gated) content is blocked server-side, so search engines can’t index it; that’s a deliberate trade-off, not a bug.

Related: Headless CMS SEO, JavaScript SEO