HugoのSEO
Hugoはビルド時に静的HTMLを出力し、初回取得のraw HTMLにコンテンツを含めます。ただしCore Web Vitalsやランキングは自動的に保証されず、canonical、taxonomyの重複、aliasesと301の違い、baseURLのプレビュードメイン問題を設定する必要があります。
言語
このページには証拠シグナルが1件あります
- 関連するライブツールCanonicalization Checker
HugoはMarkdownをビルド時に完成した静的HTMLへ変換するため、最初の取得時点でコンテンツがraw HTMLにあり、JavaScriptレンダリングキューを待ちません。ただし静的出力だけでCWV、canonical、クロール可能性、インデックス登録、ランキングは保証されません。Hugoの作業はcanonical、taxonomy、aliases、schema.html、baseURL、sitemap、robots.txt、hreflang、デプロイ後の出力を確認することです。
TL;DR — Hugoは、誰かが訪れる前にサイト全体をプレーンなHTMLファイルへビルドします。Googleが来た時点でコンテンツはすでにあり、JavaScriptを待つ必要がありません。SEOの出発点としては優れています。ただし「静的」は「自動最適化」を意味しません。canonicalタグを追加し、自動生成されるタグページに注意し、Hugoのリダイレクトが本物の301ではないことを覚えておく必要があります。
Hugoとは
Hugoは、Markdownで書いた文章とテンプレートを、完成したHTMLページのフォルダーへ変換するツールです。コンピューターまたはビルドサーバー上で前もってビルドし、そのプレーンなHTMLファイルをアップロードします。Google、Bing、読者のいずれかがページを要求すれば、最初の応答で完全なHTMLを受け取ります。 Evidence for this claim Hugo generates a static site from source content and templates. Scope: Hugo build output. Confidence: high · Verified: Hugo: Getting started ビルドとデプロイは別の手順です。コンテンツ、データ、テンプレート、設定を変更しても、再ビルドして新しい出力が実際にデプロイされるまで公開状態にはなりません。このページは現在のHugo v0.164.xの文書を説明しています。実行中のバージョンで具体的な仕様を再確認してください。
これは、読み込み後にブラウザーがページを組み立てる一般的なJavaScriptアプリとは逆です。Hugoでは組み立てるものが残っておらず、すでに完了しています。Hugoはこの処理が非常に速いことでも知られており、何千ページあっても多くのサイトは1秒未満でビルドできます。
SEOに良い理由
- コンテンツがraw HTMLに入っています。 Googleはテキストやリンクを見るためにJavaScriptを実行する必要がないため、「レンダリングに失敗する」余地がありません。
- 適切に設定されたホストなら、デフォルトで高速です。 プレーンなHTMLファイルは速く読み込まれ、Core Web Vitalsが悪化する一般的な原因を1つ減らします。ただし静的出力だけで、良好なCWV、クロール可能性、インデックス登録、ランキングが保証されるわけではありません。遅いホスティング、重い第三者スクリプト、壊れたビルドは依然としてそれらを損ないます。アーキテクチャを信じるだけでなく、デプロイ後の結果を確認してください。
- 壊れるものが少なくなります。 データベースがなく、クロール時にプラグインがクラッシュすることもありません。
今すぐ捨てるべき神話
HugoサイトならSEOが自動的に完璧になると思う人は多いですが、そうではありません。5 000個のHugo URLを調べた研究では、半数以上にcanonicalタグがありませんでした。通常は、導入したテーマがcanonicalを追加していなかったためです。静的な基盤は優れていますが、ページ上のSEOの基本は依然として自分で整える必要があります。
初心者がつまずく3つの点
- Canonicalタグ。 テーマがページソースに
<link rel="canonical">を出力しているか確認します。出力しないテーマも多数あります(追加方法はAdvancedタブにあります)。 - タグページとカテゴリーページ。 Hugoは使ったすべてのタグとカテゴリーについてページを自動生成します。問題になるかどうかは編集上の判断であり、自動的なペナルティではありません。使い捨てのタグが200個あれば、価値の薄いページが200個できるためnoindexまたは無効化を検討します。一方、実際の検索需要がある少数のタグは残して拡充する価値があります。
- リダイレクトではない「リダイレクト」。 Hugoの
aliases機能はリダイレクトを作るように見えますが、meta refreshで訪問者を移動させる小さなHTMLページを生成するだけで、本物の301ではありません。 Evidence for this claim Hugo aliases generate pages that redirect with meta refresh rather than HTTP 301 responses. Scope: Hugo alias behavior. Confidence: high · Verified: Hugo: Aliases サイト移行では重要なので、front matterを読むだけでなく実際にリクエストし、ホストが本当にその動作を返すか確認してください。
決して忘れてはいけないこと
Hugoサイトはスナップショットです。最後にビルドした時点で正しかった状態を表示します。価格を変え、誤字を直し、記事を公開しても、再ビルドして再デプロイするまでGoogleには届きません。 したがってHugoでの基本的な規律は、変更が確実に新しいビルドを起動するようにすることです。
canonicalと、デプロイを静かに壊す baseURL のバグ、taxonomy戦略、hreflang、JSON-LD、コピーして使える <head> 設定まで含む完全な技術版を読みたい場合は、Advancedタブへ切り替えてください。
Evidence for this claim Hugo renders content and templates to static output during its build. Scope: Hugo static site generation. Confidence: high · Verified: Hugo documentationTL;DR — Hugo(現行文書はv0.164.xを対象)は、ビルド時にすべてのルートを静的HTMLへ事前レンダリングするため、最初のクローラーリクエストより前にレスポンスへコンテンツが入ります。Web Rendering ServiceもWave 2の遅延もありません。これでリスクの大きな分類を1つ除けますが、良好なCore Web Vitals、正しいcanonical、クロール可能性、インデックス登録、ランキングが自動的に保証されるわけではありません。テンプレート、ホスティング、コンテンツに依存するため、デプロイ後の出力を確認してください。SALT.agencyの5 000 URLのベンチマーク(第三者研究で、このパスでは独立再検証していません)では、Hugoサイトの53,50 %にcanonicalタグがなく、90,96 %にhreflangがありませんでした。どちらも見落としやすいという実態と方向性が一致します。Hugoの大きな落とし穴はtaxonomyページ(自動生成され、問題かどうかは自分で判断する)、aliases(meta refreshで、301ではないため移行の危険要因。実際のホスト応答を確認)、
schema.htmlpartial(JSON-LDではなくmicrodata)、そしてすべてのcanonicalを誤ったホストへ向け得るbaseURLのプレビュー用ドメインバグ です。これは別のURL書き換え設定であるcanonifyURLsと混同しないでください。Sitemapとrobots.txtは組み込みですが、デフォルトと、ビルド対象を決めるbuildDrafts/buildFuture/buildExpiredフラグは明示的に調整する必要があります。<head>とビルド設定を正しくすれば、Hugoは出荷しやすい低リスクのアーキテクチャの1つです。
Hugoが先行できる理由:レンダリングキューがない
Hugoはビルド時にMarkdownとGoテンプレートを純粋な静的HTML、CSS、JSへ変換します。データベースも、リクエストごとのサーバーサイドレンダリングも、コンテンツを表示するためのクライアント側JavaScriptもありません。 Evidence for this claim Hugo renders content and templates to static output during its build. Scope: Hugo static site generation. Confidence: high · Verified: Hugo documentation そのためHugoは、JSレンダリングのSPA(React、Vue)やサーバーレンダリングのCMS(WordPress、Drupal)とは異なる、完全事前レンダリングのカテゴリーに入ります。以下はHugo v0.164.xの文書に基づきます。テンプレート関数、デフォルト、設定オプションはバージョンで変わるため、実際に実行するバイナリで再確認してください。生成とデプロイも別手順です。ビルドはディスク上に出力を作りますが、実際にデプロイされるまで訪問者には届きません。Hugo Pipesやリモートリソースを使う場合は、キャッシュキーと maxAge の設定により、デプロイ後も古いアセットが配信されることがあります。hugo --gc またはキャッシュバスターの削除で、意図的にキャッシュを更新してください。
Googleに限って言えば、Hugoサイトはレンダリングキューを完全に回避します。Googleの処理はcrawl → render → indexで、JavaScriptのレンダリングは別のキュー処理です。“the page may stay on this queue for a few seconds, but it can take longer than that.” (翻訳)「ページはこのキューに数秒とどまることがありますが、それより長くかかる場合があります」。Hugoページはそのキューに入りません。コンテンツはWave 1のraw HTML取得に存在します。Googleは動的レンダリングを回避策として明示的に廃止し、現在は “server-side rendering, static rendering, or hydration” (翻訳)「サーバーサイドレンダリング、静的レンダリング、またはハイドレーション」を推奨しています。HugoはGoogleが直接挙げる静的レンダリングを生成します。
この性能も同じ性質から生まれます。最新のCDN(Cloudflare Pages、Netlify)では、HugoのTTFBは約50 ms未満になり得るため、LCPの下限を低くできます。SALT.agencyの5 000 Hugo URLのベンチマーク(第三者研究で、このパスでは独立再検証していません)では、モバイルPageSpeedの中央値は94で、50未満は1,10 %だけでした。高速CDN上の静的HTMLはCore Web Vitalsが悪化する一般的な原因を1つ除きますが、アーキテクチャだけで良好なCWV、正しいcanonical/status code、クロール可能性、インデックス登録、ランキングを保証するわけではありません。テンプレート、ホスティング設定、コンテンツに依存するため、フレームワークがやってくれたと決めつけずデプロイ後の出力を確認してください。
Hugoが提供するものと、自分で構築するもの
| 組み込み(設定は必要) | 追加するもの |
|---|---|
sitemap.xml(デフォルトでは changefreq/priority を省略) | canonicalタグ(多くのテーマは省略) |
robots.txt テンプレート(または /static/robots.txt) | JSON-LD構造化データ |
| Open Graph + Twitter Card partial(呼び出しが必要) | taxonomyのnoindex/無効化戦略 |
schema.html partial — microdataであり、JSON-LDではない | hreflang(多言語サイトでも必要) |
| 画像処理(resize、WebP、EXIF除去) | ページ分割ページの自己canonical |
| 多言語モード + 言語別sitemap | 本物の301リダイレクト(aliasesではない) |
この表のパターンは明快です。Hugoは発見のための仕組みを標準で解決しますが、canonical化と構造化データは自分に残します。ベンチマークがエコシステムの失敗を示すのは、まさにそこです。
Canonicalタグ — エコシステム最大の空白
最も一般的で、最も直しやすいHugo SEOの失敗は、SALT.agencyによる5 000 URLの調査で、Hugoサイトの53,50 %にcanonicalタグがまったくなかったことです。第三者研究で、このパスでは独立再検証していないため、数字は権威ある確定値ではなく方向性として扱ってください。それでも実際の傾向とは一致します。人気のスターターテーマの多くはcanonical partialを出力しないため、どちらかを想定せず自分のテーマのレンダリング済み <head> を確認してください。
あなたの <head> partialに置く標準的な実装:
<link rel="canonical" href="{{ .Permalink }}" />個別ページが別の場所を指せるよう、front matterで上書きする場合:
{{- if isset .Params "canonical" -}}
<link rel="canonical" href="{{ .Params.canonical }}" />
{{- else -}}
<link rel="canonical" href="{{ .Permalink }}" />
{{- end }}すべてのcanonicalを静かに壊す baseURL バグ
ここが落とし穴です。ローカルではすべて正常に見えるため、厄介です。.Permalink は baseURL 設定から作られます。Cloudflare Pages、Netlifyなどのプラットフォームは、デプロイごとに固有のプレビューURL(abc123.yourproject.pages.dev)を割り当てます。本番ビルドがそのプレビューURLを baseURL として実行されると、サイト上のすべてのcanonicalタグが誤ったドメインを指します。Open Graph URLとsitemapのエントリーも同じです。
修正は、ビルド時に必ず本番ドメインを渡すことです:
hugo --minify --baseURL "https://yourdomain.com/"Cloudflare Pagesでは、自動検出に任せずビルドコマンドを明示するか、環境変数に HUGO_BASEURL を設定します。設定を変えるたびにデプロイ後の <head> ソースを抜き打ち確認してください。この種のバグは数週間隠れます。
これを canonifyURLs と混同しないでください。 この設定オプションは、生成時に対象となる相対URLを絶対URLへ書き換えるものです。URL書き換えの設定であり、canonicalタグの方針ではありません。オン・オフを切り替えても <link rel="canonical"> が存在するか、正しいかは変わりません。canonicalタグそのものが存在し正しいことを確認する唯一の方法は、<head> の出力を監査することです。
Taxonomyページ — Hugo最大のSEO落とし穴
Hugoは設定されたtaxonomy用語ごとにページを自動生成します。/tags/hugo/、/categories/seo/、さらに各用語の一覧ページです。生成は自動ですが、結果が問題かどうかは自動では決まりません。taxonomyページのインデックス可能性とsitemap掲載はテンプレートと設定が決めることで、重複コンテンツの自動失敗ではありません。実際には、使い捨てタグの長い末尾が薄い類似ページになり、クロールバジェットを薄めることがあります。デフォルトを放置せず明示的に決める価値があります。選択肢は3つです:
- ランディングページとして使わないなら完全に無効化する:
disableKinds: ['taxonomy', 'term'] - ナビゲーション用に残しつつ、用語ページをnoindexにする:
{{ if .Data.Singular }} <meta name="robots" content="noindex"> {{ end }} - 本物のランディングページとして投資する。
_index.mdで本文を追加し、実際の検索需要がある用語(例:/categories/technical-seo/)を役立つハブにする。
重要な後続作業が1つあります。noindexにしたページはsitemapから自動削除されません。 Hugoは同期してくれないため、taxonomyページをnoindexにするならsitemapからも除外してください(ページ単位の sitemap: { disable: true })。そうしないと、インデックスしないよう指示しながら同じURLを送信することになります。
Sitemapとrobots.txtのデフォルト
Hugoはプロトコルv0.9に準拠した sitemap.xml を自動生成します。単一言語サイトには1ファイル、多言語サイトには言語別sitemapとルートの sitemapindex.xml があります。 Evidence for this claim Hugo generates sitemap files and supports configurable sitemap fields, including multilingual sitemap indexes. Scope: Current Hugo sitemap configuration. Confidence: high · Verified: Hugo: Sitemap templates ただし、デフォルトでは期待されるフィールドが省略されます。changeFreq は空で、priority は -1 であり、設定しない限り出力から落ちます。さらに重要なのは、Hugoがコンテンツの日付から lastmod を出力することです。正確な日付にしてください。正直な lastmod は、Googleが再クロールのスケジュールに実際に使う数少ないsitemapシグナルの1つです。
robots.txt を使うには enableRobotsTXT: true を設定します(デフォルト出力は許可的で、User-agent: * とdisallowなしです)。Hugoのテンプレート言語でテンプレート化できますが、robots.txtテンプレートはsitemap変数にアクセスできません。sitemap URLをハードコードする必要があります。代替は、プレーンな /static/robots.txt ファイルを置き、enableRobotsTXT: false を設定する方法です。
Sitemapとrobotsの出力は、その実行でHugoが実際にビルドしたコンテンツだけを反映します。何がビルドされるかは、draft、将来日付、期限切れコンテンツを含めるかどうかを個別に決める buildDrafts、buildFuture、buildExpired フラグで制御されます。プレビューまたはCI設定を本番ビルドが誤って引き継ぐと、意図しないURLを公開したり、逆に省略したりします。ローカルやプレビューのデフォルトに頼らず、本番ビルドでフラグを明示し、設定変更後は言語とページ種別ごとに生成されたsitemapとrobots出力を確認してください。組み込みテンプレートがサイトの必要なケースをすべて扱うとは限りません。
Open Graph、Twitter Cards、構造化データ
Hugoには、{{ partial "name.html" . }} で呼び出す3つの組み込みpartialがあります。opengraph.html、twitter_cards.html、schema.html です。知っておくべき点は2つあります:
-
テーマが呼び出さない限り、partialは呼び出されません。 多くのテーマは3つの一部だけを接続しています。
baseof.htmlに不足しているものを追加してください。特にTwitter Cardsには絶対URLが必要なので、absURLを使い、relURLは使わないでください。 -
schema.htmlはSchema.orgのmicrodataを出力し、JSON-LDではありません。 これはHugo SEOで最も一般的な誤解です。JSON-LDはGoogleが推奨する形式であり、custom partialとして自分で構築する必要があります:<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "headline": {{ .Title | jsonify }}, "datePublished": "{{ .Date.Format "2006-01-02" }}", "dateModified": "{{ .Lastmod.Format "2006-01-02" }}" } </script>(ユーザー由来の文字列には
jsonifyを使い、引用符や特殊文字がJSONを壊さないようにします。)
URL、aliases、移行の危険
Hugoは末尾スラッシュ付きの「きれいなURL」(/about/)をデフォルトにします。紛らわしい名前の uglyURLs: true は /about.html 型のパスを生成します。これは美観ではなくファイル構造の設定です。どちらか1つを選んで一貫させ、両方の形式を解決させないでください。
実際に人を困らせるのは、Hugoのaliasesが301リダイレクトではないことです。front matterの aliases フィールドは、<meta http-equiv="refresh"> タグを含むHTMLファイルを生成します。これはクライアント側の移動であり、サーバー側の301ではありません。日常的な見栄えのよいURLなら問題ありませんが、URLを移動しリンク評価を確実に渡す必要があるサイト移行ではmeta refreshは不適切です。代わりにプラットフォーム側のリダイレクト(Netlify/Cloudflare Pagesの _redirects、またはホストのリダイレクト規則)を使い、Hugoが競合するmeta-refreshファイルも生成しないよう disableAliases: true を設定します。Hugoが制御するのは生成だけで、訪問者やクローラーが受け取る実際のHTTP応答はホストに依存します。front matterを信じるだけでなく、デプロイ済みURLへ curl -I でリクエストして実際の動作を確認してください(正しい移行の全体像はサイト移行を参照)。
多言語とhreflang
Hugoは本格的な多言語サポートを備えています。言語サフィックス付きファイル(about.en.md / about.fr.md)と、別のコンテンツディレクトリという2つの翻訳方法があり、hreflang用に .AllTranslations と .IsTranslated を公開します。それでも同じ(未検証の第三者)SALT.agencyの数字では、Hugoサイトの90,96 %にhreflangがありません。多言語サイトも含まれており、デフォルトでは誰も接続しない手動作業だという実態と一致します。実装は短いものです。何を生成しても、デプロイ後の出力で実際のalternate、canonical、sitemapの関係も検証してください。多言語設定は構造を作るだけで、タグが正しい証明にはなりません:
{{ range .AllTranslations }}
<link rel="alternate" hreflang="{{ .Lang }}" href="{{ .Permalink }}">
{{ end }}メイン言語で既知の多言語sitemap canonical競合にも注意してください。正しいと決めつけず、ビルド後に生成されたすべてのsitemapを確認します。
ページネーション
Hugoのデフォルトのページネーションはcanonicalを調整しません。ページ分割された各ページが1ページ目をcanonicalにしてしまい、深いページのコンテンツがインデックスから外れる可能性があります。ページ分割された一覧で自己参照canonicalを設定するには:
{{ if gt $paginator.PageNumber 1 }}
<link rel="canonical" href="{{ .Permalink }}page/{{ $paginator.PageNumber }}/" />
{{ else }}
<link rel="canonical" href="{{ .Permalink }}" />
{{ end }}Googleは2019年頃に rel="prev"/rel="next" を廃止しましたが、Bingは今も使っています。別の検索エンジンにも対応するため、ページネーションの発見用に追加する価値があります:
{{ if .Paginator.HasPrev }}
<link rel="prev" href="{{ .Paginator.Prev.URL | absURL }}" />
{{ end }}
{{ if .Paginator.HasNext }}
<link rel="next" href="{{ .Paginator.Next.URL | absURL }}" />
{{ end }}画像と性能
Hugoの組み込み画像処理はAVIF、BMP、GIF、JPEG、PNG、TIFF、WebPを扱います(WebP出力はv0.83.0以降)。Resize、Crop、Fill、Fit、Filterの各メソッドがあり、ビルド時にレスポンシブな srcset を生成するには十分です。ただし、変換時にEXIFメタデータが削除されます。altテキストやキャプションは画像に埋め込まれたデータではなく、必ずテンプレート属性から与えてください。
性能はHugoの本当の強みですが、簡単に取り戻されます。ベンチマークを悪化させるのは、すべてビルド後に追加したものです。第三者スクリプト、最適化されていない画像、minificationの省略が該当します。hugo --minify または設定の [minify] minifyOutput = true でminificationを有効にし、追加したanalytics/embedスクリプトを監査してください。静的サイトのスコアを落とすのはHugoではなく、それらです。
SEOのためのテーマ選び
テーマに大きく依存するため、採用前に監査してください。PaperModはOpen Graph、Twitter Cards、Schema.orgを備え、Congoもよく保守されている選択肢です。HugoMods SEO moduleは、不足しているテーマへSEO partialを補完できます。テーマを評価するときは、実際の記事のレンダリング済みソースを見て、自己参照canonical、meta description、Open Graphタグ、taxonomyページのnoindex(または無効化)戦略、JSON-LDを確認します。欠けていれば、53,50 %問題を引き継ぐことになります。
このページの位置付け
HugoはStatic Site Generatorsハブで扱う6つのジェネレーターの1つです。最も近い仲間はJekyllとEleventy(いずれもJavaScript不要)で、Gatsby/Astroはコンポーネントベースです。GoogleがJavaScriptをどう扱うか、静的出力がなぜ低リスク側なのかという広いレンダリングの文脈は、親のJavaScript SEOハブを参照してください。
AIによる要約
Advanced版の要点をまとめます:
- HugoはGoベースの静的サイトジェネレーターです。 ここではv0.164.xの文書を対象とし、Markdown + templateをビルド時に完成したHTMLへ変換します。最初の取得でraw HTMLにコンテンツがあり、JavaScriptレンダリングキューもWave 2の遅延もありません。Googleは静的レンダリングを明示的に推奨しています。生成とデプロイは別で、リソースキャッシュを意図的に更新しないと古いアセットが配信されます。
- 静的出力は結果を保証しません。 レンダリング失敗という一般的な原因を減らしますが、良好なCWV、正しいcanonical、クロール可能性、インデックス登録、ランキングはテンプレート、ホスティング、コンテンツに依存します。デプロイ後の結果を確認してください。SALT.agencyの5 000 URLベンチマーク(第三者研究で独立再検証なし)では、モバイルPageSpeedの中央値は94でした。
- 「静的」≠「最適化済み」。 同じベンチマークでは、Hugoサイトの53,50 %にcanonicalタグがなく、90,96 %にhreflangがありません。テーマが両方を省略しがちな傾向と一致します。
- Canonical:
<link rel="canonical" href="{{ .Permalink }}">をfront matterの上書きとともに追加します。デプロイプレビューURL(Cloudflare Pages、Netlify)が全canonicalを誤ったドメインへ向けるbaseURLバグに注意し、常に--baseURL https://yourdomain.com/でビルドします。canonifyURLsは別のURL書き換え設定で、canonicalタグの方針ではありません。 - Taxonomyページは用語ごとに自動生成されます。問題かどうかは編集上の判断です。無効化、noindex、拡充のいずれかを選び、noindexページはsitemapから自動削除されないことを覚えておきます。
- Aliasesはmeta-refreshリダイレクトであり、301sではありません。 移行にはプラットフォームのリダイレクトと
disableAliases: trueを使い、実際のホスト応答を確認します。 schema.htmlはmicrodataを出力し、JSON-LDではありません。 JSON-LDはcustom partialとして構築します。- Sitemapとrobots.txtは組み込みですが、デフォルトでは
changefreq/priorityが省略され、buildDrafts/buildFuture/buildExpiredがビルド対象を決めます。lastmodを正確にし、本番ではフラグを明示します。 - hreflangは
.AllTranslationsで簡単に追加できますが、ほとんど誰も設定していません。テンプレートだけでなく生成されたalternateとsitemapを検証します。 - ページネーションには自己canonicalと、Bing向けの
rel=prev/nextが必要です。Hugoはcanonicalを調整しません。 - 唯一の普遍的な落とし穴はビルドの鮮度です。 静的サイトは最後にデプロイされたビルドを反映するため、コンテンツ編集から再ビルドとデプロイまでを接続します。
公式ドキュメント
Hugoと検索エンジンの一次資料です。
Hugo
- Sitemap template と sitemap configuration — 自動生成sitemapの出力とデフォルトの変更方法。
- robots.txt template —
enableRobotsTXT、テンプレート探索順、静的ファイルの代替。 - Embedded templates — 組み込みの
opengraph.html、twitter_cards.html、schema.htmlpartial。 - URL management — pretty/ugly URLと、
aliases(meta refresh)の仕組み。 - Multilingual mode — 翻訳方法、
.AllTranslations、言語別sitemap。 - Image processing — 形式、メソッド、WebP出力、EXIF削除の動作。
- Minify configuration —
minifyOutputと形式別オプション。 - All settings —
baseURL、canonicalタグではなくURL書き換えを行うcanonifyURLs、コンテンツ状態フラグbuildDrafts/buildFuture/buildExpired。 - Taxonomies — taxonomyとtermページの設定と生成。
- Configure file caches — キャッシュキー、
maxAge、リソース/リモートデータの鮮度に関する--gc。 - Introduction — 生成と実際の公開を分けるビルド後デプロイの流れ。
- JavaScript SEOの基本を理解する — Hugoの静的出力が飛ばす2段階のレンダリング。
- Dynamic rendering (deprecated) — Googleが代わりに推奨するサーバーサイドレンダリング、静的レンダリング、ハイドレーション。
- Core Web Vitals — LCP ≤ 2,5 s / INP ≤ 200ms / CLS ≤ 0,1 の基準。
出典からの引用
GoogleとHugo自身の位置付けによる、記録に残る声明です。
Google — 静的レンダリングは推奨される方法
- “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines… Instead, we recommend that you use server-side rendering, static rendering, or hydration as a solution.” (翻訳)「動的レンダリングは回避策であり、検索エンジンにおけるJavaScript生成コンテンツの問題への長期解決策ではありません……代わりに、解決策としてサーバーサイドレンダリング、静的レンダリング、またはハイドレーションを使うことを推奨します。」 — Google Search Centralの動的レンダリング文書。Hugoは静的レンダリングを生成します。 出典
Google — Hugoが回避するレンダリングキュー
- “The page may stay on this queue for a few seconds, but it can take longer than that.” (翻訳)「ページはこのキューに数秒とどまることがありますが、それより長くかかる場合があります。」 — レンダリングキューについてのGoogle Search Central JavaScript SEO basics。事前レンダリング済みのHugoページはそこへ入りません。 出典
John Mueller、Google Search Relations — 静的ツールだけではSEOにならない
- “AI tools can build websites fast, but they won’t set up your canonicals, sitemaps, or robots.txt unless you tell them to.” (翻訳)「AIツールはWebサイトを速く構築できますが、指示しない限りcanonical、sitemap、robots.txtを設定してくれません。」 — 同じ論理はHugoテーマにも当てはまります。フレームワークは速くても、canonicalを整える仕事は残ります。 掲載記事
Hugo — 速度
- Hugoは “the world’s fastest framework for building websites” (翻訳)「世界で最も速いWebサイト構築フレームワーク」と自称しています。大規模なコンテンツで意味を持つビルド速度上の利点です。 出典
避けるべきHugo SEOの失敗
Hugoサイトを出荷するときに実際に起きる、よくある失敗とそれぞれの修正方法です。
テーマがcanonicalタグを追加すると信じる
「静的サイト」なら「SEO対応済み」だと考えるのが、Hugoで最も一般的な失敗です。なぜ誤りか: SALT.agencyの5 000 URLベンチマークでは、Hugoサイトの53,50 %が <link rel="canonical"> なしで出荷されていました。テーマがpartialを追加していないだけです。代わりにすること: テーマを信頼する前に実際のページでview-sourceを確認し、なければcanonical partialを自分で追加します(正確なテンプレートはAdvancedタブを参照)。
プレビューURLのプラットフォームで自動検出ビルドコマンドを使う
なぜ誤りか: Cloudflare PagesとNetlifyはデプロイごとに固有のプレビューURLを割り当てます。本番ビルドがそれを baseURL として引き継ぐと、.Permalink がすべてのcanonical、Open Graph URL、sitemapエントリーを一度に汚染します。ローカルの hugo server では完全に正常に見えます。代わりにすること: ビルドコマンドを明示し、--baseURL "https://yourdomain.com/" を渡すか、環境変数に HUGO_BASEURL を設定します。設定変更後はデプロイ済み <head> を抜き打ち確認してください。
サイト移行に aliases を使う
なぜ誤りか: Hugoの aliases front-matterフィールドは、<meta http-equiv="refresh"> タグを持つHTMLページを生成します。クライアント側の移動であり、301ではありません。何百ものURLを移行してリンク評価を確実に渡す必要がある場合、meta refreshでは不十分です。代わりにすること: プラットフォーム側のリダイレクト(Netlify/Cloudflare Pagesの _redirects またはホストの規則)で移行し、Hugoが競合するmeta-refreshファイルも出さないよう disableAliases: true を設定します。
組み込みの schema.html partialがJSON-LDを出すと思う
なぜ誤りか: schema.html はSchema.orgのmicrodataを出力し、JSON-LDではありません。Googleが実際に推奨する形式ではないため、呼び出して終わりにすると、ツールからレガシー形式として扱われる構造化データだけが残ります。代わりにすること: <script type="application/ld+json"> ブロックを出力する小さなcustom partialを作り、ユーザー入力の文字列には jsonify を通します。
計画なしでtaxonomyページを有効にする
なぜ誤りか: Hugoはすべてのタグとカテゴリーについてページを自動生成します。使い捨てタグの長い末尾は、薄く似たページの山となってクロールバジェットを薄め、重複コンテンツのシグナルを招く可能性があります。代わりにすること: 最初に、disableKinds: ['taxonomy', 'term'] で無効化するか、noindexにするか、実際の検索需要がある少数の用語へ投資するかを決めます。
Taxonomyページをnoindexにしながらsitemapに残す
なぜ誤りか: Hugoは2つを自動同期しません。noindex を付けたページが sitemap.xml に残り、Googleにスキップを指示しながら同じURLを送ることがあります。代わりにすること: taxonomyページをnoindexにするたび、ページ単位の sitemap: { disable: true } で同じページをsitemapから除外します。
Hugo SEOでよくある問題
Hugoサイトを公開した後に読者が実際に遭遇する問題を、症状から調べる一覧です。
どのページにもview-sourceでcanonicalタグがない
原因: テーマが baseof.html のcanonical partialを呼び出していません。これは多くのHugoテーマのデフォルト状態です。修正: head partialへ <link rel="canonical" href="{{ .Permalink }}" /> を追加し、必要なページにはfront-matterの上書きを用意します。PatrickのCanonical CheckerでURLを確認するか、Scriptsタブの grep -rL 'rel="canonical"' public --include="*.html" 監査を再実行し、空の結果になることを確認してください。
Canonicalタグはあるが、.pages.dev または localhost ホストを指す
原因: 本番ビルドがデプロイプレビューURLを baseURL として実行されました。.Permalink はそこから派生するため、すべてのcanonicalが誤ったドメインを引き継ぎます。修正: hugo --minify --baseURL "https://yourdomain.com/" で再ビルドするか、CI/ビルド設定で HUGO_BASEURL を明示し、再デプロイします。その後Canonical Checkerまたは grep -rho 'rel="canonical" href="[^"]*"' public | sort | uniq -c で確認し、実ドメインだけが出ることを確認します。
移行後も古いURLが、きれいなリダイレクトではなく目に見えるフラッシュ付きで解決する
原因: 移行がHugoの aliases フィールドに依存しています。これはmeta-refresh HTMLページを生成するクライアント側の移動で、サーバー側301ではありません。修正: プラットフォーム側の本物のリダイレクト(Netlify/Cloudflare Pagesの _redirects、または同等のホスト規則)を追加し、競合するmeta-refreshファイルを止めるため disableAliases: true を設定します。Redirect Checkerで確認し、200 + refreshタグではなく単一ホップの301を求めます。
Google Search Consoleがtaxonomyページを重複または薄いコンテンツとして報告する
原因: Hugoが、編集上の計画なしにすべての用語について /tags/… または /categories/… ページを自動生成しました。修正: 3つの方法から選びます。kindを disableKinds: ['taxonomy', 'term'] で無効化する、ナビゲーションを残してtermページをnoindexにする、またはランディングページにする価値のある少数の用語へ実際の本文を追加する。どの方法でも、Hugoが自動で行わないsitemapからの除外も実施します。
多言語サイトでhreflangエラー(「return tagなし」またはalternate欠落)が出る
原因: .AllTranslations が <head> partialに接続されていません。SALT.agencyのベンチマークでは、多言語サイトも含めHugoサイトの90,96 %にhreflangがありません。修正: {{ range .AllTranslations }}<link rel="alternate" hreflang="{{ .Lang }}" href="{{ .Permalink }}">{{ end }} をhead partialへ追加し、再ビルドします。その後Google Search ConsoleのInternational Targetingレポートでreturn-tagエラーが消えたことを確認します。
GitまたはCMSで公開したコンテンツ編集が本番サイトに現れない
原因: Hugoはスナップショットジェネレーターです。サイトを再ビルドして再デプロイするまで訪問者には届きません。壊れた、または欠落したCI/CMS webhookは、変更をmerge済みにしたままビルドを起動しないことがあります。修正: 該当コミットのビルドプラットフォームのデプロイログを確認します。ビルドが走っていなければwebhookの接続を確認し、手動で再ビルドしてパイプライン自体が動くことを確かめます。
Hugo SEOチェックリスト
Hugoサイト(または監査中のテーマ)が基本を満たしているか確認するためのチェックです。
- Canonicalタグがすべてのページのレンダリング済みソースにある(
<link rel="canonical">)。テーマが追加すると決めつけない。 - デプロイ済みビルドの
baseURLが本番ドメインである(.pages.dev/ previewホストの漏れをlive canonicalで確認)。 - Sitemapを生成してGoogle Search ConsoleとBing Webmaster Toolsへ送信し、
lastmodが正確である。 - robots.txt が存在し(templateまたは
/static/)、CSS/JSやインデックスしたいものをブロックしていない。 - Taxonomy戦略を決めた(無効化、noindex、または実際のランディングページとして拡充)。
- noindexページをsitemapから除外した(Hugoは自動同期しない)。
- Open Graph + Twitter Card partialを
baseof.htmlで実際に呼び出し、絶対URLを使う。 - JSON-LDをcustom partialとして追加した(組み込み
schema.htmlはmicrodataだけ)。 - 多言語サイトで
.AllTranslationsによるhreflangを接続した。 - ページ分割ページが自己canonicalになり、Bing向けに
rel=prev/nextを追加した。 - Aliasesとリダイレクト: 移行ではプラットフォーム側の本物の301sを使い、必要なら
disableAliases: true。 - minificationを有効にし(
--minify)、追加した第三者スクリプト/画像をCWVについて監査した。 - コンテンツ編集が再ビルド + 再デプロイを起動する(CMS/Git webhook)。静的サイトは最後のビルドだけを表示する。
メンタルモデル
1. 静的化が解決するのはレンダリングであり、canonical化ではない。 Hugoはレンダリングキューのリスク分類を無料で取り除きますが、重複コンテンツ、canonical、構造化データの判断には何もしません。フレームワークが助けないところへ労力を使ってください。そこがベンチマークで皆が失敗している場所です。
2. テーマがSEOの表面である。
Hugoサイトで「canonical / OGタグ / JSON-LDがあるか」は、実際には「テーマがそれらを出力するか」です。テーマを信頼する前に実際の記事のレンダリング済み <head> を監査してください。canonical欠落53,50 %はテーマの統計です。
3. ビルド時とサーバー時を分ける。
Hugoが決めることは、全員に対してビルド時に一度決まります。baseURL、canonical、sitemap、コンテンツはすべてビルド時に凍結されます。その帰結は、悪い baseURL がすべてのURLを一度に汚染し、コンテンツ変更は次のビルドまで誰にも届かないことです。
4. 「リダイレクトのように見える」≠「301である」。 Hugo aliasesはmeta-refresh HTMLを生成します。日常的な見栄えのよいURLなら許容できますが、移行では危険です。重要度に合わせてツールを選び、移行にはプラットフォームの301、低リスクのショートカットだけにaliasesを使います。
5. 自動生成≠必要。 Taxonomyのtermページと空のsitemapフィールドは、役立つかどうかに関係なく生成されます。Hugoの自動出力は、完成品ではなく削るための初稿として扱ってください。
Hugo SEO — チートシート
組み込みと、自分で行うこと
| 項目 | Hugoのデフォルト | 自分で行うこと |
|---|---|---|
| レンダリング | 静的HTML、JSキューなし | 何もしない — 無料で得られる利点 |
| Sitemap | 自動 sitemap.xml、changefreq/priority は空 | 正確な lastmod を設定し、noindex URLを除外 |
| robots.txt | 許可的(enableRobotsTXT 使用時) | template化するか /static/ を使い、sitemap URLをハードコード |
| Canonical | ないことが多い(テーマ依存) | <link rel="canonical" href="{{ .Permalink }}"> を追加 |
| 構造化データ | schema.html = microdata | JSON-LD partialを手作業で構築 |
| OG / Twitter | 組み込みpartial | baseof.html で呼び出し、absURL を使う |
| Taxonomyページ | 用語ごとに自動生成 | 無効化 / noindex / 拡充 |
| リダイレクト | aliases = meta refresh | 移行にはプラットフォーム301s + disableAliases: true |
| hreflang | .AllTranslations が使える | <head> で反復する |
| ページネーション | Canonicalは調整されない | 深いページを自己canonicalにし、Bing向けに rel=prev/next を追加 |
baseURL の修正(省略しない)
hugo --minify --baseURL "https://yourdomain.com/"プレビュー用デプロイURL(*.pages.dev、Netlify preview)を baseURL に使うと、canonical、OG URL、sitemapが静かに汚染されます。
ベンチマークの速見データ(SALT.agency、5 000 Hugo URL — 第三者研究で、このパスでは独立再検証していません)
- **53,50 %**にcanonicalタグがない。
- **90,96 %**にhreflangがない。
- モバイルPageSpeedの中央値は94、50未満は**1,10 %**だけ。
- これらはあなたのビルドを保証しない — 自分のデプロイ後出力を確認する。
神話 → 現実
- 「Hugo = 完璧なSEO」→ 半数のサイトでcanonicalが欠けている。
- 「Aliasesは301s」→ meta refreshである。
- 「
uglyURLsは醜い」→/page.htmlと/page/の違いにすぎない。 - 「
schema.htmlはJSON-LDを出す」→ microdataを出す。 - 「
rel=prev/nextは死んだ」→ Googleは廃止したが、Bingは今も使う。
正しいbaseURLでビルドする(最重要の修正)
最も深刻なHugo SEOバグは、デプロイプレビューURLを baseURL として本番ビルドし、すべてのcanonicalを汚染することです。常に本番ドメインを明示的に渡してください。
macOS / Linux
# Production build — minified, correct canonical domain
hugo --minify --baseURL "https://yourdomain.com/"Windows (PowerShell)
hugo --minify --baseURL "https://yourdomain.com/"Cloudflare Pagesでは、これをビルドコマンドとして設定するか(または HUGO_BASEURL を環境変数として設定する)、自動検出されたビルドに頼らないでください。
ビルド済みサイトでcanonical欠落を監査する
ビルド後、出力は public/ にあります。これは生成HTMLからcanonicalタグがないページをgrepします。ローカルで53,50 %問題を捕捉できます。
macOS / Linux
# List built HTML files with NO rel="canonical"
grep -rL 'rel="canonical"' public --include="*.html"Windows (PowerShell)
# List built HTML files with NO rel="canonical"
Get-ChildItem -Recurse public -Filter *.html |
Where-Object { -not (Select-String -Path $_.FullName -Pattern 'rel="canonical"' -Quiet) } |
Select-Object -ExpandProperty FullNameCanonicalが正しいホストを指すことを確認する
canonicalにプレビュードメインが漏れていないかを簡単に確認します。
macOS / Linux
# Show every canonical href and how many times each host appears
grep -rho 'rel="canonical" href="[^"]*"' public | sort | uniq -c | sort -rnWindows (PowerShell)
Select-String -Path public\*.html -Pattern 'rel="canonical" href="([^"]*)"' -Recurse |
ForEach-Object { $_.Matches.Groups[1].Value } | Group-Object | Sort-Object Count -Descending出力に *.pages.dev、Netlify preview、localhost ホストがあれば、ビルド時の baseURL が誤っています。上の修正で再ビルドしてください。
Hugo SEOのためのツール
- Hugo CLI(
hugo --minify --baseURL …) — minification、重要なbaseURL、taxonomy用のdisableKindsなど、ビルド時のSEO制御はここにあります。 - View Source / GSC URL Inspection — canonical、metaタグ、JSON-LDがレンダリング済みHTMLに実際にあることを確認します。静的サイトではView Sourceが真実です。
- Google Search Console + Bing Webmaster Tools — 自動生成sitemapを送信し、インデックスを監視し、Bingでは
rel=prev/nextのページネーションを確認します。 - PageSpeed Insights / CrUX — 静的CDNの性能上の利点を検証し、ビルド後に追加した第三者スクリプトによるCWV回帰を検出します。
- クローラー / サイト監査 — Ahrefs Site AuditまたはScreaming Frogでデプロイ済みサイトをクロールし、欠落したcanonical、薄いtaxonomyページ、大規模なmeta-refresh aliasesを見つけます。
- HugoMods SEO module — canonical、OG、JSON-LDを欠くテーマへSEO partialを補完します。
- Scriptsタブの
grep監査 — 出荷前にcanonical欠落と誤ったbaseURLを見つける最速の方法です。
Hugoの修正が実際に反映されたことを証明する
テンプレートを編集しただけでなく、特定のHugo SEO修正が正しく出荷されたことを確認する合否テストです。
Canonicalタグが存在し、正しいドメインにある
実行するテスト: 本番ドメインの主要ページ(ホーム、記事、taxonomyページ)をCanonical Checkerに通すか、ローカルで grep -rho 'rel="canonical" href="[^"]*"' public | sort | uniq -c を実行します。期待結果: すべてのページが実際の本番ホスト上で、自己参照canonicalをちょうど1つ返します。失敗の解釈: canonicalがなければテーマpartialが欠けています。.pages.dev/localhost ホストなら baseURL がビルド時に誤っていました。監視期間: 即時。悪いビルドコマンドはいつでも再発させるため、デプロイごとに再確認します。ロールバック条件: 本番以外のホストへ解決するcanonicalが1つでもあれば、誤った baseURL で出荷したため、他の作業より先に再ビルドします。
Sitemapが有効で、noindex URLを列挙していない
実行するテスト: taxonomyまたはnoindexを変更したら、sitemap.xml をSitemap Validatorへ送信します。期待結果: sitemapが有効なXMLとして解析され、列挙されたURLがすべてインデックス可能(noindexを伴わない)です。失敗の解釈: noindex URLがsitemapに残るのは、taxonomyの sitemap: { disable: true } を省略したことを示します。Hugoはnoindexとsitemap除外を自動同期しません。監視期間: ビルド直後、taxonomyページを積極的に整理するなら週次。ロールバック条件: noindex URLがsitemapに残ること。
移行URLがmeta refreshではなく本物の301を返す
実行するテスト: 移行URLのサンプルにRedirect Checkerまたは curl -I <old-url> を使います。期待結果: 新URLへの単一ホップの 301(または 308)で、中間の200 + meta-refreshページがありません。失敗の解釈: リダイレクトを持つ200は、移行がプラットフォーム規則ではなくHugoの aliases に依存していることを示します。監視期間: 切り替え時に即時、その後CDNキャッシュが安定した約1週間後。ロールバック条件: 古いURLが301ではなく200/meta-refreshを返すこと。
JSON-LDが有効(custom partialを追加した場合)
実行するテスト: custom JSON-LD partialを追加した後、レンダリング済みページをGoogleのRich Results TestまたはPatrickのSchema Validatorで検査します。期待結果: 対象のschema type(例:Article)が必須フィールドエラーなしで解析されます。失敗の解釈: parseエラーは通常、jsonify を通さなかったエスケープされていない値、または誤ったHugo変数を参照したフィールドが原因です。監視期間: 即時、さらに <head> に触れるテーマまたはテンプレート更新後。ロールバック条件: 以前なかったschemaエラーが出たら、フィールドを直すまでpartialを戻します。
自分でテストする:Hugo SEO
Hugoが代わりに処理するものと、自分に残すものについての簡単な5問です。各問に答えてから確認してください。
時間を使う価値のある資料
私の関連記事
- JavaScript SEO: A Definitive Guide — レンダリング、DOM parity、静的/事前レンダリング出力が低リスク側である理由。
- The Beginner’s Guide to Technical SEO — 大きな全体像でレンダリングアーキテクチャとcanonical化がどこに入るか。
私の講演
- How Search Works(SlideShare)— クロール、レンダリング、インデックス登録、ランキングについての解説。(継続的な免責事項:“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳)「これはシステムについての私の理解であり、100%完全または正確になるとは限りません」)
業界の資料
- Hugo documentation — sitemap、robots.txt、組み込みpartial、多言語モード、画像処理のcanonicalな参照。
- SALT.agency — Hugo SEO benchmark data — canonical欠落53,50 %とhreflang欠落90,96 %の根拠となる5 000 URL調査。
- CloudCannon — Hugo SEO best practices — チェックリスト形式の実務的な解説。
- HugoMods SEO module — canonical、OG、JSON-LDを欠くテーマ用の追加SEO partial。
- グーグル 検索センター — JavaScript SEOの基本 — Hugoの静的出力が省略できる2段階レンダリング。
- ジョン・ミューラーによるAIコーディングとSEOの基本(Search Engine Journal)— 高速なツールでもcanonical、sitemap、robots.txtまでは設定しないこと。
変更履歴
2026年8月20日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。
2026年7月18日に更新。
編集概要と記録された変更の詳細。変更の詳細
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
-
変更の詳細な注記は現在英語でのみ提供されています。
完全な比較は利用できません — この改訂の以前のスナップショットがアーカイブされていません。