GhostのSEO

TL;DR — Ghostは、通常モードならサイトマップ、canonical、メタタグ、ソーシャルカード、構造化データなど、技術SEOの大部分をプラグインなしで自動処理する公開プラットフォームです。初期状態でも高速です。ただし「ヘッドレス」（別サイトのコンテンツソースとして使う構成）では、組み込みSEOがすべて消え、開発者が再構築しなければなりません。会員限定コンテンツはGoogleに表示できません。

Ghostとは

Ghostはコンテンツ管理システムです。WordPressに似ていますが、あらゆる種類のサイトではなく、ブログ、ニュースレター、有料会員向けに作られています。Ghostで記事を書き、Ghostが公開します。

SEOでGhostが異なるのは、まったく違う2つの方式で運用できることです。

• 通常方式（従来型）。 Ghostがサイト全体を動かし、コンテンツを保存してウェブページに変換します。大半のユーザーが使う方式です。
• ヘッドレス方式。 Ghostはコンテンツの保管庫になります。Next.jsやAstroなどで作った別サイトがコンテンツを取得し、自分でページを構築します。

この選択がGhost SEOのすべてを変えるため、常に意識してください。

Ghostが通常モードで自動処理すること

Ghostを通常方式で運用すると、設定なしで技術SEOの基本を静かに処理します。

• サイトマップ — yourdomain.com/sitemap.xmlに自動更新されるページ一覧を作り、Googleと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タグ — 検索エンジンにページの「公式」版を伝え、重複ページの競合を防ぎます。
• メタタイトルと説明 — 空欄なら妥当な代替値を使います。
• ソーシャルカード — 共有時に見栄えがよくなるOpen GraphとTwitter Cardタグです。
• 構造化データ — 検索エンジンが記事を理解するためのArticleマークアップです。
• クリーンなURLと、初期状態での高速なサイトです。

WordPressならこの多くを得るためにYoastのようなプラグインを入れます。Ghostでは最初から使えます。

Ghostがしないこと

Ghostは中核を扱いますが、追加機能は扱いません。パンくずやFAQの構造化データ、多言語（hreflang）サイトの組み込み対応、記事ごとの「Googleから隠す」切り替え、Yoast型のキーワードチェックリストはありません。コードまたは第三者ツールが必要です。

多くの人が誤解している1点

会員限定コンテンツは順位を得られません。 有料または無料メール会員の背後に記事を置くと、ログインしていない人（検索エンジンを含む）からGhostが隠すため、Googleは読めません。順位を狙う公開プレビューやティーザーを用意し、限定部分で購読へ転換します。ロックされた記事から検索流入を期待しないでください。

従来型とヘッドレスの選択、ヘッドレス再構築チェックリスト、限定コンテンツのスキーマ、Ghost Proとセルフホストの違いは、Advancedタブで扱います。

TL;DR — Ghost SEOは、従来型（Handlebars）とヘッドレス（Content API）の選択で分岐します。従来型は、サイトマップ、自己参照＋カスタムcanonical、メタタグ、OG／Twitterカード、Article JSON-LDをプラグインなしで自動生成し、初期状態でも高速です。ヘッドレスにするとすべて消え、フロントエンドが再構築するため、速度の利点もフレームワーク側の責任になります。どちらにもパンくず／FAQ／Productスキーマ、hreflang、記事ごとのnoindex、IndexNow、リダイレクトUIという空白があります。会員限定コンテンツはサーバー側で保護されるため登録できません。2方式を混同しないでください。

分岐点

GhostはNode.js（Express）のCMSで、コアが分離されています。APIと、任意のHandlebarsフロントエンドという構成が、SEOの全体像です。

• 従来型 — GhostはHandlebarsテーマでHTMLを配信します。組み込みSEOはテーマの{{ghost_head}}ヘルパーから自動生成されます。
• ヘッドレス — Ghostは*“a full headless CMS which is completely agnostic of any particular front end or static site framework.”* (翻訳)「特定のフロントエンドや静的サイトフレームワークに完全に依存しない、フル機能のヘッドレスCMS」です。別フロントエンド（Next.js、Astro、Nuxt、SvelteKit）からContent APIまたはAdmin APIを呼び出し、SEOは100％そのフロントエンドの責任になります。

方式の選択がGhost SEOの規模を決める最大の要因です。 以下はすべてこの選択を軸に整理します。ヘッドレス全般についてはヘッドレスCMSのSEOを参照してください。

従来型Ghostが自動処理すること

従来型では、Ghostが設定なしで中核の技術SEOを処理します。

• サイトマップ。 /sitemap.xmlに自動生成し、公開／非公開時に更新します。記事、ページ、タグ、著者を含みます。Ghostは*“Ghost automatically creates and updates an XML sitemap for your website.”* (翻訳)「GhostはウェブサイトのXMLサイトマップを自動作成・更新します」と説明しています。 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タグ。 すべての記事とページにrel=canonicalを自己参照で置きます。“Ghost adds canonical tags across your site to tell search engines which version of a page they should consider the ‘official’ one.” (翻訳)「Ghostはサイト全体にcanonicalタグを追加し、検索エンジンにページのどの版を『公式』とみなすか伝えます。」2019年3月以降は、エディターのメタデータパネルまたはAdmin APIのcanonical_urlで記事ごとのカスタムcanonicalも設定できます。これは*“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
• メタタイトル／説明。 空欄なら記事タイトルと抜粋へフォールバックします。
• Open Graph＋Twitter Cards。 記事メタデータとアイキャッチ画像から自動生成します。
• 構造化データ（JSON-LD）。 “Ghost automatically includes structured data in all posts and pages” (翻訳)「Ghostはすべての記事とページに構造化データを自動的に含めます」。publisher、author、headline、datePublished、dateModified、画像、keywordsを持つArticleスキーマです。
• クリーンURLとカスタムルーティング。 初期値はスラッグ型で、routes.yamlから完全に変更できます。
• robots.txt。 管理パス/ghost/をdisallowし、それ以外を許可するデフォルトファイルです。

WordPressの標準インストールより、これは実際に多くを備えています。Ghostは*“XML sitemaps, canonical tags, optimised URLs, microformats, Facebook Open Graph tags, support for Twitter cards and clean semantic markup”* (翻訳)「XMLサイトマップ、canonicalタグ、最適化URL、マイクロフォーマット、Facebook Open Graphタグ、Twitterカード対応、クリーンなセマンティックマークアップ」を、プラグイン不要の組み込み機能として挙げています。

どちらの方式でもGhostがしないこと

Ghostは中核で止まります。次を自動生成しません。

• 高度なスキーマ。 パンくず、FAQ、HowTo、Product、Recipe、Video。Articleスキーマだけで、他はコード注入またはテーマ作業です。
• hreflang／国際SEO。 ネイティブ対応はなく、WeglotやConveyThisなどの第三者サービス、またはテーマ実装が必要です。
• 記事ごとのnoindex切り替え。 UIにはなく、コード注入が必要です。
• キーワード最適化の助言。 GhostチームはYoast型ツールについて、“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,” (翻訳)「YoastのKW最適化提案の欠点の1つは、人間ではなく機械向けにメタデータを書くよう促すことです」と述べ、さらに高度なSEO機能の要望には*“This isn’t on our radar at the moment.”* (翻訳)「現時点でその予定はありません」と答えています。
• IndexNow。 ネイティブ対応はなく、必要なら公開Webhookで接続します。
• リダイレクト管理UI。 self-hostedではredirects.yaml、Ghost Proではリダイレクトマネージャーを使います。頼れるプラグインエコシステムはありません。

ヘッドレスGhost：再構築するSEO

ヘッドレスにするとGhostはSEOシステムではなくコンテンツAPIになります。「自動処理」一覧はすべてフロントエンドの仕事です。

• サイトマップ — ビルド時またはContent APIを呼ぶサーバーレス関数で生成します。
• canonicalタグ — フロントエンドが、1つのSITE_URLから絶対URLを注入します。
• メタ＋OG／Twitterタグ — フレームワークのhead管理（Next.jsのgenerateMetadata、Astroの<head>、NuxtのuseSeoMeta）で出力します。
• 構造化データ（JSON-LD） — すべてカスタムです。
• robots.txt — フロントエンドが配信します。
• 301／302リダイレクト — フロントエンドまたはCDN層で処理します。
• Core Web Vitals — Ghostの速度優位は消え、フレームワークとレンダリング方式が性能を決めます。

引き継がれるのは、Content APIがエディターに入力したメタデータ（meta_title、meta_description、og_title、og_description、og_image、twitter_title、twitter_description、twitter_image、canonical_url）を返すことです。データはありますが、レンダリングは自分の責任です。これはヘッドレスCMS全般のSEO問題で、JavaScript SEOの問題でもあります。フロントエンドがクライアント側レンダリングを初期値にすると、Googlebotは後のレンダリング波まで待つ必要があります。AIクローラーの対応はプロバイダーで異なるため、カバレッジを最大化するにはSSR／SSGでサーバーまたはビルド時にレンダリングします。

限定コンテンツとGoogleが見られるもの

Ghostにはpublic、members-free（メール必須）、members-paid（購読）の3つの公開レベルがあります。SEO上の重要点は、限定コンテンツがユーザーエージェント判定ではなくサーバー側でブロックされることです。Ghostチームは*“Google can’t crawl protected content on your page, because that’s only ever available to logged in members.”* (翻訳)「保護されたコンテンツはログイン済み会員だけが利用できるため、Googleはページ上の保護コンテンツをクロールできません」と説明しています。ログアウト読者と同じ制限ビューをGoogleに返します。

現実的な戦略は2つです。

1. 公開プレビュー。 冒頭や最初の数段落を公開し、残りを限定します。Ghostのネイティブ公開プレビューなら、公開部分が順位を担います。
2. メータリング。 第三者実装で、登録を求める前に無料記事を数本読めるようにします。

限定する場合、Googleはペイウォール用マークアップ（NewsArticle、isAccessibleForFree: false、限定領域を示すhasPart／cssSelector）をサポートします。ただしGhostは自動生成しないためコード注入が必要です。いずれにせよ、クローキングはしないでください。読者にはペイウォールを見せながらGooglebotに全文を見せるとガイドライン違反で、手動対策のリスクがあります。公開コンテンツが順位を取り、限定コンテンツが転換するという整理が正直です。

Ghost Proとセルフホスト

両方のSEOソフトウェアは同じです。同じGhost、同じ機能で、違いはインフラのコントロールです。

• Ghost Pro — CDN、SSL自動化、バックアップ付きの管理ホスティングです。CDNは分散ユーザーのTTFBとCore Web Vitalsに役立ちます。ただし**robots.txtを直接上書きできず**、サポートへ連絡する必要があります。ヘッドレスやprivate modeでは現実的な制約です。
• セルフホスト — サーバー、ヘッダー、キャッシュ、robots.txt、サーバーリダイレクト、自前CDN（Cloudflareが一般的）を完全に制御できます。高度な技術SEOの自由度は高い一方、管理も増えます。

どちらがSEOに本質的に「優れている」わけではありません。Ghost ProはCDNを、セルフホストはコントロールを買う選択です。

よくある落とし穴

• 薄いタグ／著者アーカイブ。 Ghostは/tag/slug/と/author/slug/を自動作成します。細かすぎるタグや1記事だけの著者は薄いページを作るため、低価値なものはnoindexを検討します。
• プレビューURLの登録。 古いGhostでは、プレビューに読み込まれた第三者スクリプト経由で下書きURLがGooglebotに漏れることがありました（コアで修正済み。GitHub issue #9749参照）。古いインストールでは確認します。
• /ghost/の露出。 管理パスのデフォルトrobots.txt disallowが上書きされていないことを確認します。
• カスタムコレクションによる重複。 routes.yamlで同じコンテンツに別URLパスを作れます。デフォルト構造はcanonical化されますが、カスタムルーティングは明示的に管理しないと重複を作ります。
• 転載／ゲスト投稿のカスタムcanonical不足。 他所のコンテンツを再公開するなら、記事ごとのcanonical_urlを元URLへ設定します。機能は2019年3月以降です。
• ヘッドレスの公開前登録。 公開前に独自robots.txtなしでヘッドレスフロントエンドをデプロイすると、早期登録されます。Ghostのprivate modeはDisallow: /を返しますが、Ghost本体を守るだけで別フロントエンドは守りません。

GhostとWordPressの簡単な比較

Ghostは設定なしでより多くのSEOを備え、初期状態でも高速です（Ghost自身のベンチマークは*“up to 1,900% faster than WordPress”* (翻訳)「WordPressより最大1,900%高速」と主張します。ベンダー値として扱うべきですが、最小限のJavaScriptと強いCWV基準という方向性は現実的です）。WordPressは適切なプラグインでスキーマ、リダイレクト管理、プログラムSEOを追加でき、上限は高い一方、プラグイン依存が性能を損ねることがあります。SEOプラグインの負担なく書きたい出版社にはGhost、複雑なサイトや高度な連携にはWordPressが向きます。「速いから順位が上がる」は単純化で、Core Web Vitalsは多くの要因の1つです。ヘッドレスGhostの速度はフロントエンド次第です。

AI要約

Advanced版を凝縮すると、次のとおりです。

• Ghost SEOは1つの選択で分岐する。 従来型（Handlebars）とヘッドレス（Content API）で、方式がGhost SEOの最大の決定要因です。
• 従来型Ghostはプラグインなしで中核SEOを提供する。 /sitemap.xmlのサイトマップ、自己参照canonical（2019年3月以降は記事ごとのカスタムcanonical）、代替値付きメタタイトル／説明、OG／Twitterカード、Article JSON-LD、クリーンURL、/ghost/をdisallowするrobots.txtを自動生成し、初期状態でも高速です。
• ヘッドレスGhostではすべて失われる。 APIはメタデータを返しますが、フロントエンドがサイトマップ、canonical、メタタグ、構造化データ、robots.txt、リダイレクトを再構築します。SSR／SSGで出力し、CSRだけにしません。
• 両方式の空白。 パンくず／FAQ／Productスキーマ、hreflang、記事ごとのnoindex、IndexNow、リダイレクトUIはありません。GhostはYoast型ツールを「機械向けに書く」ものとして退けています。
• 限定コンテンツは登録できない。 サーバー側でブロックされ、Googleはログアウト読者と同じものを見ます。公開プレビューで順位を取り、残りを限定して転換します。クローキングはしません。
• Ghost Proとセルフホスト。 SEO機能は同じです。ProはCDNを追加しますがrobots.txt変更はサポート経由、セルフホストは完全な制御を得ます。
• 落とし穴。 薄いタグ／著者アーカイブ、古い版のプレビューURL、カスタムroutes.yamlによる重複、転載記事のカスタムcanonical不足です。

公式ドキュメント

検索エンジンとGhost自身による一次資料です。

Google

• JavaScript SEOの基礎 — ヘッドレスGhostに直結するクロール→レンダリング→インデックスの流れと、CSRが遅れて見える理由です。
• 購読・ペイウォールコンテンツを有効にする — 限定コンテンツのNewsArticle、isAccessibleForFree、hasPart／cssSelectorです。
• noindexで検索インデックスをブロックする — プレビューや管理パス用のnoindexメタタグとX-Robots-Tagヘッダーです。
• サイトマップの概要 — 送信方法と、従来型Ghostが自動生成するサイトマップを説明します。

Bing／Microsoft

• Bing Webmaster Tools — サイトマップを送信する — Ghostの/sitemap.xmlを直接送信します。
• IndexNow／indexnow.org — Ghostがネイティブ対応しないプッシュプロトコルで、公開Webhookへ接続します。

Ghost（公式）

• Ghost Help — SEO — Ghostが自動処理する内容の基準リストです。
• Ghost Developer Docs — アーキテクチャ — フロントエンドに依存しないヘッドレスCMSとしてのGhostです。
• Ghost Docs — URLとルーティング — routes.yaml、コレクション、カスタムURL構造です。
• Ghost Changelog — カスタムcanonical URL — 2019年3月の記事単位canonical機能です。
• Ghost Resources — 会員サイトのSEO — 限定コンテンツSEOに関するGhost自身の整理です。

出典からの引用

Ghostの文書とチームによる記録に残る発言です。各リンクは引用箇所へ移動するディープリンクです。

Ghost — 組み込みSEO機能

• “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は、検索エンジンがサイト構造を理解しすべてのコンテンツを見つけられるよう、ウェブサイトのXMLサイトマップを自動作成・更新します。」 — Ghost Help Docs. 引用箇所へ
• “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はサイト全体にcanonicalタグを追加し、検索エンジンにページのどの版を『公式』とみなすか伝えます。これにより重複コンテンツの問題を防ぎます。」 — Ghost Help Docs. 引用箇所へ
• “Ghost automatically includes structured data in all posts and pages. This helps search engines understand the content and context of your pages.” (翻訳)「Ghostはすべての記事とページに構造化データを自動的に含め、検索エンジンがページのコンテンツと文脈を理解できるようにします。」 — Ghost Help Docs. 引用箇所へ

Ghost — ヘッドレスアーキテクチャ

• “Ghost is a full headless CMS which is completely agnostic of any particular front end or static site framework.” (翻訳)「Ghostは、特定のフロントエンドや静的サイトフレームワークに完全に依存しない、フル機能のヘッドレスCMSです。」 — Ghost Developer Docs. 引用箇所へ

Ghost — 限定コンテンツとクロール

• “Google can’t crawl protected content on your page, because that’s only ever available to logged in members.” (翻訳)「保護されたコンテンツはログイン済み会員だけが利用できるため、Googleはページ上の保護コンテンツをクロールできません。」 — Kym, Ghost team, Ghost Forum. 引用箇所へ

Ghost — カスタムcanonical URL（2019年3月）

• 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エディターでカスタムcanonicalリンクを直接実装できます。」 — Ghost Changelog. 引用箇所へ

Ghost — 高度なSEO機能について（チーム回答）

• “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.” (翻訳)「YoastのKW最適化提案の欠点の1つは、人間ではなく機械向けにメタデータを書くよう促すことです。」 — Ghost team, Ghost Forum. 引用箇所へ
• 高度なSEO機能（パンくずスキーマ、hreflang、noindex制御）の要望に対して：“This isn’t on our radar at the moment.” (翻訳)「現時点でその予定はありません。」 — Ghost team, Ghost Forum. 引用箇所へ

Ghost — パフォーマンス（ベンダーベンチマーク）

• “Independent tests have found Ghost to be up to 1,900% faster than WordPress.” (翻訳)「独立テストでGhostはWordPressより最大1,900%高速だと判明しています。」 — Ghost vs WordPress page. 引用箇所へ

2つのチェックリスト：従来型Ghost＋ヘッドレスGhost

従来型Ghost — 公開後に確認

• /sitemap.xmlが解決し、Google Search ConsoleとBing Webmaster Toolsへ送信されている。
• robots.txtが/ghost/をdisallowし、インデックスしたいものをブロックしていない。
• 記事／ページにcanonicalが出力され、転載・ゲスト投稿には**カスタムcanonical_url**が設定されている。
• メタタイトル／説明が設定されている（またはタイトル／抜粋の代替値でよい）。
• 共有時のOG／Twitterカードが正しくプレビューされる。
• Article JSON-LDがRich Results Testで検証できる。
• 薄い/tag/／/author/アーカイブをレビューし、低価値のものをnoindexにする。
• 検索流入を得たい会員限定記事に公開プレビューがある。
• 必要な高度なスキーマ（パンくず、FAQ、Product）はコード注入で追加されている。Ghostは自動生成しない。

ヘッドレスGhost — 完全実装チェックリスト

• フロントエンドがCSRではなくSSRまたはSSGでコンテンツを出力する（生HTMLがAIクローラーのカバレッジを最大化する）。
• Content APIからサイトマップを生成し、最新に保つ。
• レンダリング層で1つのSITE_URLから絶対URLのcanonicalを出力する。
• Content APIのメタタイトル／説明／OG／Twitterを<head>へマッピングする。
• JSON-LD構造化データをフロントエンドで再構築する。
• robots.txtをフロントエンドが配信し、.js／.cssをブロックしない。
• 301／302リダイレクトをフロントエンドまたはCDNで処理する。
• プレビュー／ブランチデプロイはホストレベルのnoindexヘッダーを返す。
• Core Web Vitalsを測定する。Ghostの速度優位は消え、フレームワークが担う。
• Bingなどへ向け、IndexNowを公開Webhookに接続する。

メンタルモデル

1. 方式が製品そのもの。 Ghost SEOの話をする前に、従来型かヘッドレスかを答えます。従来型Ghostはほぼ完成したSEOシステムで、ヘッドレスGhostは素のコンテンツAPIです。

2. 「ヘッドレスはすべて再構築する」という意味。 サイトマップ、canonical、メタタグ、OGカード、JSON-LD、robots.txtという従来型の自動処理が、フロントエンドの明示的なビルド工程になります。APIはデータを渡し、レンダリングは自分で行います。

3. Ghostは中核を扱い、追加機能は扱わない。 どちらの方式でもArticleスキーマまでです。パンくず、FAQ、HowTo、Product、hreflang、記事ごとのnoindex、IndexNowは組み込みません。必要ならコード注入や第三者ツールを計画します。

4. 公開コンテンツは順位を取り、限定コンテンツは転換する。 会員限定コンテンツは設計上検索エンジンから見えません。公開プレビューで順位を取り、ゲートで購読へ転換します。読者以上にGoogleへ見せるクローキングはしません。

5. ProとセルフホストはSEO機能ではなくインフラの選択。 SEOソフトウェアは同じです。Ghost ProはCDNを提供しますがrobots.txtを固定し、セルフホストはサーバーとCDNを完全に制御できます。

Ghost SEO — 早見表

従来型とヘッドレス：得られるもの

どちらの方式にも組み込まれないもの

• パンくず／FAQ／HowTo／Product／Recipe／Videoスキーマ → コード注入
• hreflang／国際SEO → Weglot、ConveyThis、またはテーマ実装
• 記事ごとのnoindex切り替え → コード注入
• IndexNow → 公開時のカスタムWebhook
• リダイレクトUI → redirects.yaml（セルフホスト）またはGhost Proの管理画面

限定コンテンツのルール

• 会員限定コンテンツはサーバー側でブロックされ、登録できません。
• 順位を狙うティーザーには公開プレビューを使います。
• ペイウォールスキーマ（NewsArticle＋isAccessibleForFree: false）は自動生成されず、コード注入が必要です。
• クローキング禁止。 Googlebotに全文、ユーザーにペイウォールを返すと手動対策のリスクがあります。

Proとセルフホスト

• SEO機能は同じです。
• Ghost Pro： CDN付き。robots.txt変更はサポートへの連絡が必要です。
• セルフホスト： robots.txt、ヘッダー、リダイレクト、自前CDNを完全に制御できます。

サイトマップからGhost記事を確認する例

まず関連するサイトマップをダウンロードし、代表URLの一覧をurls.txtへ抽出してから、テーマまたはヘッドレスフロントエンドが公開する内容を確認します。

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

公開、限定、タグ、著者、最近リダイレクトされた例を含めます。Ghost Content APIキーをスクリプトに入れず、公開出力を確認できます。

Ghost SEOのツール

• URL検査（Google Search Console） — Ghostページがどのようにクロール・レンダリングされたかを確認します。ヘッドレスのCSR欠落を見つけるのに不可欠です。
• Rich Results Test — 従来型の自動Article JSON-LD、またはヘッドレスのカスタムJSON-LDがテーマ／レンダリング変更後も存在し、妥当か確認します。
• Bing Webmaster Tools — Ghostのサイトマップを送信し、インデックスとIndexNow送信先を確認します。
• Screaming Frog SEO Spider — 薄いタグ／著者アーカイブ、リダイレクトチェーン、ヘッドレスの生HTMLとレンダリングHTMLの差を見つけます。
• Ahrefs Site Audit — 壊れたcanonical、メタデータ不足、インデックス可否を全体で見つけます。カスタムroutes.yamlコレクションの重複確認にも有用です。
• Ghostエディターのメタデータパネル — 記事ごとのタイトル、説明、OG／Twitter上書き、カスタムcanonical URLを設定する場所です。

避けるべきGhost SEOの誤り

Ghostを運用する人が実際に犯す具体的な誤りです。診断ではなく予防を扱います。

従来型とヘッドレスGhostを同じSEO問題として扱う。 誤りの理由：従来型はサイトマップ、canonical、メタタグ、OG／Twitterカード、Article JSON-LDを自動生成しますが、ヘッドレスは素のコンテンツAPIで何も生成しません。 代わりに：作業前に方式を確認し、対応するチェックリストに従います。

会員限定コンテンツが検索流入を生むと期待する。 誤りの理由：Ghostは限定コンテンツをサーバー側でブロックするため、Googleはログアウト訪問者と同じ制限ビューを受け、登録するコンテンツがありません。 代わりに：ネイティブの公開プレビューまたはティーザーを公開して順位を取り、限定部分で読者を転換します。

ゲートを回避するためにクローキングする。 誤りの理由：読者にペイウォールを見せながらGooglebotに全文を見せるのはガイドライン違反で、手動対策のリスクがあります。 代わりに：限定コンテンツを発見可能にしたいなら、Ghostが自動生成しないためコード注入で、Googleのペイウォール用マークアップ（NewsArticle、isAccessibleForFree: false、限定領域のhasPart／cssSelector）を使います。

カスタムcanonicalなしで転載・ゲスト投稿を公開する。 誤りの理由：Ghostのデフォルトcanonicalは自己参照なので、転載記事をそのままにすると自分が原典だと伝え、元サイトと競合します。 代わりに：エディターまたはAdmin APIで記事ごとのcanonical_urlを元URLへ設定します。この機能は2019年3月から存在します。

クライアント側レンダリングのヘッドレスフロントエンドを出荷する。 誤りの理由：GooglebotはCSRページを後のレンダリングまで待つ必要があり、AIクローラーの対応はプロバイダーごとに違います。クライアント取得後にしか存在しないコンテンツはHTML専用取得器に見えません。 代わりに：Content APIを読むフレームワークでSSR／SSGを使い、GSCのURL検査でレンダリングHTMLに本文があることを確認します。

Ghost Proがセルフホストと同じインフラ制御を持つと考える。 誤りの理由：SEOソフトウェアは同じですが、Ghost Proではrobots.txtを直接編集できず、サポートに連絡する必要があります。 代わりに：Ghost Proの公開計画にサポート待ち時間を織り込むか、短時間でrobots.txtを変更する必要があるならセルフホストにします。

どのGhost SEO経路が自分に当てはまるか？

最も重要な分岐は従来型かヘッドレスかです。ヘッドレスならフロントエンドがサーバー側でレンダリングするかも確認します。正直に答えてください。違う分岐を選ぶと不要な作業になります。

Ghost SEOタスクにそのまま使えるプロンプト

指定した入力をAIアシスタントに貼り付け、上のガイダンスと照合してから行動します。

1. ヘッドレスGhostフロントエンドの不足SEOフィールドを監査する。 貼り付けるもの：ヘッドレスフロントエンドの1ページのレンダリングHTML（ソース表示またはJS実行後のDOM）と、同じ記事のContent APIレスポンス。

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.

期待する出力：フィールドごとのチェックリストで、上の6項目のうちレンダリングHTMLに存在しないもの、またはAPIのmeta_title、canonical_urlなどと一致しないものを示します。修正前に、指摘された差分を手動で確認してください。

2. ヘッドレスGhost記事のArticle JSON-LDを作成する。 貼り付けるもの：1記事のContent APIフィールド（タイトル、抜粋、公開日、更新日、著者、アイキャッチ画像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]

期待する出力：単一の<script type="application/ld+json">ブロックです。公開前にGoogleのRich Results Testで検証してください。モデルがフィールドを誤って対応付けたり、必須プロパティを省略したりする可能性があります。

3. 転載／ゲスト投稿のカスタムcanonical不足を確認する。 貼り付けるもの：記事スラッグ、canonical_urlフィールド（未設定なら「未設定」）、転載元の元URL。

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.

期待する出力：canonicalが正しいかどうかのYes／Noと、正しくない場合にカスタムcanonicalフィールドへ貼り付ける正確なURLです。

自分で確認：Ghost SEO

Ghost CMSでSEOがどう動くかについての簡単な5問です。各問に答えてから、正解を確認してください。

時間を使う価値のある資料

自分の関連記事

• 技術SEO入門 — プラットフォームとCMSのSEOを大きな全体像に位置づけます。
• JavaScript SEOの問題とベストプラクティス — ヘッドレスGhostが生むレンダリングの問題、メタデータ、JS canonical、robots.txtの.js／.cssルールを扱います。
• Robots.txtとSEO：知っておくべきこと — Ghostの/ghost/ disallowとGhost Proのrobots.txt制約に関係します。

自分の講演

• 検索の仕組み（SlideShare） — クロール、レンダリング、インデックス、順位という、限定・ヘッドレスGhostのコンテンツが通過すべきパイプラインです。（注意書き：“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳)「これはシステムについての私の理解であり、100％完全または正確とは限りません」。）

業界の資料

• Ghost Help — SEO — Ghostが自動処理する内容の公式基準リストです。
• Ghost Developer Docs — アーキテクチャ — ヘッドレスCMSとしてのGhostとAPI／フロントエンド分離です。
• Next.jsでGhostをヘッドレスCMSとして使う（Draft.dev） — SEOを再構築する必要があるヘッドレス構成の実例です。
• GhostブログSEO：経験と結果（Norbert Hires） — Ghost運用者のデータと限界です。
• Ghostのスキーママークアップ（Bright Themes） — Ghostが生成しない高度なスキーマを追加する方法です。
• Ghostのパンくず（Bright Themes） — Ghostが省くパンくずスキーマを実装します。
• Ghostの構造化データを制御する（ashryan.io） — デフォルトJSON-LDの上書き・拡張です。
• r/TechSEO — ヘッドレスGhostのクロール／インデックス／レンダリング問題をデバッグするコミュニティです。

変更履歴