GhostのSEO標準機能を使い倒す——サイトマップ・構造化データ

WordPressからGhostに移ってきた人が最初に戸惑うのは、SEOプラグインが一つも存在しないことだ。

Yoast SEOもRank Mathも、Ghostには入らない。管理画面を探しても、サイトマップを生成するボタンもなければ、構造化データを設定する項目もない。

「SEOは自分でやれということか」と思うが、実は逆だ。Ghostは、SEOに必要な機能を最初から本体に組み込んでいる。プラグインが存在しないのは、不要だからだ。

今日は、Ghostが標準で持っているSEO機能を最短で使い倒すための設定を整理する。サイトマップ提出・OGP・構造化データ・Google Search Console連携まで、2026年の仕様で書いていく。

Ghostが標準で持っているSEO機能の全体像

最初に、Ghostが本体で面倒を見てくれている項目を並べる。

項目	Ghost標準対応	備考
sitemap.xml	◯ 自動生成	/sitemap.xml で公開される
robots.txt	◯ 自動生成	クロール許可が初期状態で入っている
OGP（Open Graph）	◯ 自動出力	Feature image・タイトル・ディスクリプションから生成
Twitter Card	◯ 自動出力	OGPと同じソースから生成
JSON-LD 構造化データ	◯ 自動出力	Article / WebSite / Person
canonical URL	◯ 自動出力	記事ごとに自動付与・手動上書きも可能
meta description	◯ 手動入力欄あり	Post settings から入力
メタタイトル上書き	◯ 手動入力欄あり	Post settings から入力

この時点で、一般的な日本語SEO記事が「Yoastで設定しましょう」と書いている項目の大半は、Ghostでは設定不要か、入力欄が一つあるだけで完了する。

プラグインが要らないのではなく、プラグインを前提にしない設計思想でGhostは作られている。この前提を理解しないままWordPress流のSEO対策を持ち込むと、同じ設定を二重三重にやってしまって逆に事故る。

サイトマップの確認とGoogle Search Console提出

Ghostは https://あなたのドメイン/sitemap.xml に自動でサイトマップを出している。

ブラウザでアクセスすると、以下の5つに分かれているのが分かる。

/sitemap-pages.xml — 固定ページ
/sitemap-posts.xml — 記事
/sitemap-authors.xml — 著者ページ
/sitemap-tags.xml — タグページ
/sitemap.xml — 上記4つをまとめたインデックス

Google Search Consoleへの提出手順

Google Search Console にアクセス
プロパティを追加（ドメインプロパティ or URLプレフィックス）
DNS TXTレコードまたはHTMLタグで所有権確認
左メニュー「サイトマップ」→ sitemap.xml と入力して送信

Ghost Proの場合、DNSはGhost側で管理されていないため、HTMLタグ確認がやりやすい。Settings → Code injection → Site Header に <meta name="google-site-verification" content="..."> を貼り付けるだけだ。

セルフホストでCloudflareを使っている場合はTXTレコード確認が楽だ。

提出後に確認すること

提出直後はインデックスが反映されず「検出 - インデックス未登録」のままになる。焦らなくていい。僕の経験で言うと、新規ドメインでインデックスが動き始めるまで最低2〜4週間はかかる。

「サイトマップを出したのに検索に出ない」とSNSで嘆いている人が多いが、それは普通だ。最初の90日はインデックスされないのが普通。この感覚を持たないままブログを始めると、3ヶ月で辞めることになる。

記事ごとのmeta title / meta descriptionを手で書く

Ghostの記事編集画面で、右サイドバー下部にある歯車アイコン（Post settings）を開くと、以下の入力欄がある。

Meta title — 検索結果に出るタイトル。空欄なら記事タイトルが使われる
Meta description — 検索結果のスニペット文。空欄なら本文冒頭が自動抽出される
Canonical URL — 重複コンテンツ対策。通常は空欄でいい
Facebook / Twitter のタイトル・説明・画像 — SNSシェア時の表示を個別に上書きできる

僕の運用ルール

Meta title は 30文字前後、記事タイトルより少し短く、キーワードを前に寄せる
Meta description は 90〜120文字、読者の「得られるもの」を最初に書く
Facebook / Twitter 欄はOGP画像をそのまま使うので基本触らない

検索結果のクリック率を決めるのは、9割がmeta titleとdescriptionだ。本文をどれだけ丁寧に書いても、ここが雑だとクリックされない。記事を書いたら最後の5分でここを書くを習慣化するだけで、3ヶ月後の流入が変わる。

この入力欄の書き方ひとつで全く違うCTRになるという現実を、WordPress出身の人は意外と軽視する。Ghostは項目数が少ない分、ひとつひとつの重みが大きい。

Feature imageとOGPの関係

Ghostの記事編集画面の一番上に貼る「Feature image」は、単なる見出し画像ではない。

Feature imageが自動で使われる場所

トップページの記事一覧のサムネイル
記事本文の先頭のヘッダー画像
OGP画像（FacebookやX/Twitterシェア時のカード画像）
構造化データ（Article.image）の画像URL

つまり、Feature imageを設定しないとOGPカードに画像が出ない。SNSでシェアされた時、文字だけの味気ないカードになる。クリック率は画像ありと比べて明確に落ちる。

推奨サイズと比率

サイズ: 1200 × 630 px（OGPの標準アスペクト比 1.91:1）
形式: JPEG（写真）/ PNG（テキスト入り）
容量: 200KB以下が目安

Post settings → Facebook card / Twitter card

OGP用にFeature imageと別の画像を使いたい場合は、Post settingsから個別指定もできる。が、これをやると画像管理が煩雑になる。基本はFeature image一枚で統一する運用がおすすめだ。

URLスラッグ設計——日本語スラッグ vs 英数字の本音

Ghostで記事を作ると、スラッグ（URLの末尾部分）が自動生成される。

日本語タイトルで書くと、初期スラッグは記事タイトルをローマ字化したもの……ではなく、日本語そのままになる。

例: 記事タイトル「Ghost入門」→ スラッグ ghost入門 or ghost-入門

日本語スラッグの問題

URLに日本語を含めると、ブラウザや外部サービスで以下のように percent-encoding される。

https://example.com/ghost-入門/
↓
https://example.com/ghost-%E5%85%A5%E9%96%80/

SNSに貼った時に読めない長いURLになる
アフィリエイトURLと組み合わせたときに事故る
一部のメールクライアントでリンクが切れる
コピーしてチャットに貼るとエンコードされた形で送られ、見栄えが悪い

結論: 英数字スラッグが無難

僕はすべての記事を英数字ハイフン区切りのスラッグで統一している。記事を書いたらPost settingsを開き、スラッグを手で書き換えるのをルーティンにしている。

例:

ghost-seo-setup（本記事）
ghost-font-css（C-02）
ghost-pro-setup（B-03）

スラッグはSEOに直接効くほど強くはないが、短く意味が伝わるスラッグのほうが外部リンクされやすい傾向はある。何より自分で管理しやすい。

内部リンクはGhostでは完全に手作業

WordPressの「Link Whisper」のような内部リンク自動挿入プラグインは、Ghostには存在しない。

Ghostで内部リンクを増やす方法は一つしかない。過去記事を覚えておいて、新記事を書くたびに手で挿入する。これだけだ。

内部リンクの貼り方のルール

記事末尾に2〜3本、関連記事を明示的にリンク
記事本文の中に、自然な文脈で1〜2本差し込む
同じアンカーテキストで複数の記事にリンクしない
新記事を公開したら、関連する既存記事にも戻って内部リンクを追加する

月イチの棚卸しを推奨

記事が30本を超えたあたりから、どの記事がどこにリンクしているか覚えきれなくなる。僕は月初に30分だけ、Google Search Consoleの「リンク」レポートを見ながら内部リンクのバランスを調整する時間を取っている。

プラグインがない分、自分の記事群を俯瞰する習慣がつく。これは結果的にメディアの構造理解につながる。楽ができないが、楽ができないから雑な量産と差がつく。AIで記事を量産して内部リンクまで自動化したメディアが軒並み壊滅した理由は、AIで記事量産したメディアが2026年に終わった理由に書いた。

JSON-LD構造化データ——Ghostが自動で出している中身

Ghostは記事ごとにJSON-LD形式の構造化データを自動で出力している。

記事ページのHTMLソースを開いて application/ld+json で検索すると、以下のような構造が見える。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "publisher": {
    "@type": "Organization",
    "name": "OurBlog",
    "logo": { "@type": "ImageObject", "url": "https://..." }
  },
  "author": {
    "@type": "Person",
    "name": "RyoN",
    "url": "https://..."
  },
  "headline": "記事タイトル",
  "image": ["https://..."],
  "datePublished": "2026-05-18T06:00:00.000Z",
  "dateModified": "2026-05-18T06:00:00.000Z",
  "mainEntityOfPage": "https://..."
}

Article / Person / Organization / ImageObject が揃って出力される。Googleの「リッチリザルトテスト」（rich-results-test）に記事URLを入れると、エラーなく通るはずだ。

ここに何も足さなくていい

一般的な記事サイトなら、この自動出力だけでGoogleの求める構造化データ要件を満たす。WordPressのSEOプラグインが何ページも設定画面を用意しているのは、プラグイン側で構造化データを生成する必要があるからで、Ghostは本体でやっているから設定画面がいらない。

標準の構造化データで足りる人は、ここは読み飛ばしていい。

ただし、コーポレートサイトを兼ねていたり、著者ページを前面に出したい場合は、追加でJSON-LDを差し込むことになる。

Organization（サイト運営者情報）を足す例

Ghost管理画面 Settings → Code injection → Site Header に以下を貼り付ける。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "OurBlog",
  "url": "https://ourblog.jp/",
  "logo": "https://ourblog.jp/content/images/logo.png",
  "sameAs": [
    "https://x.com/ourblog_jp"
  ]
}
</script>

Breadcrumb（パンくず）を記事に足す場合

Ghostの記事テーマ側で {{> breadcrumb}} のようなパーシャルを組み込み、JSON-LDを同時出力する。セルフホストかつテーマ改造前提の話なので、Ghost Proで運用している初心者は手を出さなくていい。

構造化データは出しすぎると逆効果になることがある。不正確なデータを出すとGoogleの判定が悪化する。自動出力で十分、を第一原則にしたほうがいい。

Ghost 6のExperience SEO対応——2026年の一次情報

Ghost 6系（2026年リリースの安定版）では、SEO関連でいくつか静かにアップデートが入っている。僕が運用していて気づいた変化を書いておく。

1. Tag/Author ページへのnoindex自動付与の挙動変更

Ghost 5系まではタグページ・著者ページが常にインデックス対象だった。6系ではビジビリティ設定でnoindexを選べるようになり、記事が少ないタグでの薄いページ評価リスクを下げられる。

2. Twitter Card メタの自動出力が summary_large_image 固定に

twitter:card が summary_large_image 固定になり、小さいカードを自動で使う挙動がなくなった。意図的に小カードを使いたい場合はCode Injectionで上書きするしかない。

3. canonical URLの挙動がより厳密に

Post settingsでcanonical URLを手動指定した場合、OGP・JSON-LD・<link rel=canonical> の3箇所すべてが同じURLで統一される。ここがバラついていた5系の挙動は解消された。

4. Lexicalエディタの見出しがh2 / h3に正規化

本文の見出しは自動的にh2から始まる。記事タイトルがh1になるため、本文中でh1を使いたくても使えない。これはSEO的には正しい挙動だが、WordPressから来た人は戸惑う。

これらはGhost公式のリリースノートを追いかけていても小さい扱いになっている変更点だ。実際に運用しないと見落とすポイントなので、6系で始めた人向けに残しておく。

まとめ——Ghostで「SEOを仕組みで回す」発想に切り替える

Ghostで記事を書き始める人に最初に伝えたいのは、SEOは最初の設定で9割決まるという話ではない。逆で、SEOは最初の設定を最低限済ませたら、あとは記事の中身と継続で決まるだ。

Ghostの標準機能でやることは、極論するとこれだけだ。

Google Search ConsoleでサイトマップURLを提出する
記事を書くたびにmeta title・meta description・Feature image・スラッグを整える
記事末尾と本文中に関連記事への内部リンクを手で貼る
月に一度だけ、Search Consoleのレポートを眺める

この4つを淡々と続けられる人が、6ヶ月後にはSEO流入を持っている。プラグインを何個入れても、AIで構造化データを自動生成しても、この4つをサボれば何も動かない。

個人ブログのSEOでGoogleが見ているのは、結局は誰が・どれだけ続けて・どんな経験に基づいて書いたかの三点だ。この話はE-E-A-Tと個人ブログで別途扱う予定だ。

業界の本音を最後に一つ

「GhostはSEOに弱い」と書いているブログがある。あれは、WordPressのSEOプラグインで設定項目を触ることを「SEOをやっている」と勘違いしている人の感想だ。本質的には、WordPressとGhostの間にSEO性能差はない。差が出るとすれば、それは書く人の側にある。

プラグインのGUIで満足するのをやめて、Ghostのシンプルな入力欄に中身のある文字列を毎回置いていく。それだけで、検索流入は半年後に形になって返ってくる。

Ghost自体の初期セットアップはGhost Pro初期設定ガイドに、日本語表示のCSSはGhostで游ゴシック・ヒラギノを美しく出すCSS設定にまとめている。SEO以前の土台が揃っていない場合は先にそちらを整えてほしい。

情報は執筆時点（2026年4月）のGhost 6系を前提にした。Google Search ConsoleのUI・Ghost本体のSEO挙動は今後変更される可能性があるため、最新情報は公式ドキュメントを確認すること。

Ghostが標準で持っているSEO機能の全体像

サイトマップの確認とGoogle Search Console提出

記事ごとのmeta title / meta descriptionを手で書く

Feature imageとOGPの関係

URLスラッグ設計——日本語スラッグ vs 英数字の本音

内部リンクはGhostでは完全に手作業

JSON-LD構造化データ——Ghostが自動で出している中身

Code Injectionでの追加実装——Organization / Breadcrumb を足す場合

Ghost 6のExperience SEO対応——2026年の一次情報

まとめ——Ghostで「SEOを仕組みで回す」発想に切り替える

関連記事

noteからGhostへ記事を移す最短手順——非エンジニア向け2026年版

Ghostで游ゴシック・ヒラギノを美しく出すCSS設定——和文で読ませるテーマに必要なこと

GhostでStripeを繋いで日本円課金を始める手順（2026年版）

新着記事をメールで