Web on plzhans blog

Hugoブログを作る - 始め方からSEOまで

Thu, 03 Sep 2026 00:00:00 +0000

概要

このブログ自体がこの順番で構築されました。Notionで記事を書きMarkdownに変換してHugoでビルドし、GitHub Pagesにデプロイするパイプラインから、カスタムドメインの接続、多言語対応、セキュリティヘッダーまで順番に整理しました。

なぜこの組み合わせなのか

静的サイトはサーバーを別途運用する必要がなく、GitHub Pagesのような無料ホスティングに載せるだけでそれ自体が高速で安定します。問題は「静的」という言葉どおり執筆の体験が不便になりがちな点ですが、NotionをCMSとして使うとこの問題が解決します — 普段使っているエディタで記事を書き、APIでNotionページをそのままMarkdownとして取り込んでビルドすればよいのです。Hugoは静的サイトジェネレーターの中でもビルド速度が速く、テーマのエコシステムが整っているため選びました。

全体アーキテクチャ

Notion(記事作成) → 同期スクリプト(Notion APIでMarkdownに変換) → Hugo(静的サイトビルド) → GitHub Actions(コミット時に自動ビルド・デプロイ) → GitHub Pages(ホスティング) → Cloudflare(CDN・セキュリティヘッダー)の順でつながっています。記事を書いて「発行要求」状態に変えるだけで、あとは自動化されたパイプラインが処理してくれます。

構築の順番

まず基本のブログを作る → Hugo + GitHubでブログを作る
自分のドメインを接続する → GitHub Pagesでカスタムドメインを使う方法
複数言語に拡張する → Hugoサイトで多言語対応する
セキュリティヘッダーで仕上げる → SEO監査が指摘するセキュリティヘッダー4つを、Cloudflareでコードなしに適用する

Hugo + GitHubでブログを作る — 基本パイプライン

Notion→Markdown→Hugoビルド→GitHub Pagesデプロイの流れ全体を整理しました。Hugoのインストール、m10cテーマの適用、GitHub Actionsによる自動デプロイ、baseURL設定でよくあるミスまで扱います。この段階だけ終えても、執筆からデプロイまで完全に自動化されたパイプラインが手に入ります。

→ Hugo + GitHubでブログを作る

GitHub Pagesカスタムドメイン — 自分のドメインを接続する

CNAME・A/AAAAレコードの設定、GitHub PagesのCustom domain適用手順、Actionsデプロイとブランチデプロイでのcnameファイル処理の違い、CAAレコードのせいでEnforce HTTPSが有効にならない原因まで整理しました。github.ioサブドメインの代わりに自分のドメインを使うと、ブランディングだけでなく検索エンジンにもより一貫したシグナルを送れます。

→ GitHub Pagesでカスタムドメインを使う方法

Hugo多言語対応 — SEOまでカバーする

多言語ブログでbaseURL、sitemap、robots、JSON-LD、Open Graph、meta descriptionを設定し、hreflang・canonicalで重複コンテンツの問題を防ぐ方法を整理しました。言語別のsitemapを別々に管理しないとインデックスの問題につながりやすい部分なので、最初から構造を整えておくことが重要です。

→ Hugoサイトで多言語対応する

セキュリティヘッダー — SEO監査が指摘する理由

HSTS・CSP・X-Content-Type-Options・Referrer-PolicyをSEO監査がなぜ指摘するのか、値が固定されたヘッダーはCloudflare Transform Rulesで、頻繁に変わるCSPはHTML metaタグで管理する方法を整理しました。静的サイトなのでサーバーの設定ファイルがない分、こうしたヘッダーはCDNやmetaタグのレベルで別途対応する必要があります。

SEO監査が指摘するセキュリティヘッダー4つを、Cloudflareでコードなしに適用する

Sun, 30 Aug 2026 01:25:00 +0000

概要

SEO監査レポートで、4つのセキュリティヘッダーが指摘されることがあります。Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options、Referrer-Policyです。

最初はなぜこれがSEO項目なのかと思うはずです。結論から言うと、これらのヘッダーは検索順位を直接上げてくれるわけではありません。

この記事では、なぜSEO監査にセキュリティヘッダーが含まれるのか、各ヘッダーが何をするのか、そしてCloudflareを前段に置いた静的ブログで後から管理しやすい組み合わせで適用する方法を整理します。

なぜSEOレポートがセキュリティヘッダーを指摘するのか

Lighthouseスコアに含まれている

ほとんどのSEO監査ツールはGoogle Lighthouseをベースに技術SEOスコアを算出します。Lighthouseの4つのカテゴリのうち1つがBest Practicesで、ここにCSP、HSTS、X-Content-Type-Optionsのチェックが含まれています。

厳密にはセキュリティ衛生の点検なのですが、SEO監査フレームワークに組み込まれて一緒に報告されているのです。検索エンジンがこのヘッダーを読んで順位付けしているわけではありません。

本当のつながりはハッキングされた時の結果

実質的なつながりは次の経路です。

XSSやコンテンツインジェクションでスパムリンクや悪意のあるスクリプトが挿入される。
Google Safe Browsingが検索結果に警告を付けるか、インデックスから除外する。
トラフィックが一夜にして消える。

セキュリティヘッダーは1番が起こる確率を下げる予防措置です。監査レポートがこの項目を高優先度に分類するのは、発生確率が高いからではなく、起きた時のインパクトが大きいからです。

💡 まとめると「セキュリティヘッダー → 順位上昇」ではなく、「セキュリティヘッダー不在 → ハッキングリスク → (発生した場合)順位崩壊」という間接的で非対称な関係です。ユーザーアップロードもログインフォームもない静的ブログなら攻撃対象領域そのものが小さいため、優先度としては致命的というよりは、やっておくと安全な予防接種に近いものです。

各ヘッダーの役割

Strict-Transport-Security (HSTS)

ブラウザに対して、このドメインには今後必ずHTTPSでのみ接続するよう指示します。http://でリクエストが発生してもサーバーに確認せず、ブラウザが即座にhttps://に変換します。

すでに301でHTTPSリダイレクトをしていても、その最初のリクエストの瞬間は平文です。公共Wi-Fiのような環境で攻撃者が中間で傍受し、偽のページを表示するSSLストリッピングが可能な区間がまさにここです。HSTSはその区間をなくします。

Content-Security-Policy (CSP)

スクリプト、画像、スタイルをどの取得元から読み込めるかを定めるホワイトリストです。中核となる役割はXSS防御です。

外部依存(コメントウィジェット、アナリティクスなど)のいずれかがサプライチェーン攻撃を受けたり、コンテンツパイプラインのバグでエスケープされていないテキストがそのままHTMLに入り込む事故が起きても、許可されていない取得元からのスクリプト実行をブラウザが拒否します。

一次防御線が突破されても機能する二次防御線だと考えてください。

X-Content-Type-Options: nosniff

ブラウザがサーバーの示したContent-Typeを無視して、ファイルの内容を見て種類を自ら推測するMIMEスニッフィングを防ぎます。

この推測が悪用されると、実行されてはいけないファイルがスクリプトとして実行される迂回経路が生まれます。ユーザーアップロードのないブログならリスクは低いですが、副作用がないためそのまま有効にしておく項目です。

Referrer-Policy

訪問者が他のサイトへ移動したり外部リソースを読み込んだりする際、どのページから来たのかをどこまで渡すかを定めます。

最近のブラウザは何も指定しなくてもデフォルト値がすでにstrict-origin-when-cross-originになっています。以前のデフォルトだったno-referrer-when-downgradeは、プロトコルさえ同じであればパスまで含めた完全なURLを渡していましたが、2020年の仕様改定で基準が変わりました。

そのため、この項目は「今まさに情報が漏れている」というよりは、ブラウザのデフォルト値に依存せず、サイトが望むポリシーを明示しておくという意味合いが大きいです。SEOよりも訪問者のプライバシーの性格が強い項目です。

どこに何を置くか

ヘッダーを全部Cloudflareに集約することもできますし、全部HTMLに入れることもできます。実際に運用してみると、値が変わる頻度が基準になります。

ヘッダー	置き場所	理由
Strict-Transport-Security	Cloudflare	一度有効にすれば変わることがない
X-Content-Type-Options	Cloudflare	値が`nosniff`固定である
Referrer-Policy	Cloudflare	metaでもできるがヘッダーの方が確実
X-Frame-Options	Cloudflare	値が固定で、metaでは代替できない
Content-Security-Policy	HTML meta	外部サービスを追加するたびに値が変わる

CSPだけ性格が異なります。アナリティクスを乗り換えたりコメントウィジェットを追加するたびに許可元を修正する必要があり、これをCloudflareに置くと**サイトをいじるたびにダッシュボードに入らなければなりません。**サイトのリポジトリで一緒に管理する方がはるかに楽です。

Cloudflareに置くヘッダー

1. HSTSとnosniffは1画面で完結する

SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Enable HSTS

Hugoサイトで多言語対応する

Wed, 11 Feb 2026 09:55:00 +0000

目的

Hugoブログに多言語対応とSEO最適化を適用し、検索エンジンへの露出を最大化するとともに、多言語ユーザーに適切な言語バージョンを提供します。

SEO設定

SEO(Search Engine Optimization、検索エンジン最適化)とは、Googleなどの検索エンジンがサイトのコンテンツを正しく理解し、検索結果に表示できるように、サイト構造とメタデータを最適化する作業です。

この文書では、ブログに適用されたSEO設定をまとめます。

1. 絶対URL - Hugo baseURL設定

ファイル: hugo/hugo.toml
内容: baseURL = 'https://blog.plzhans.com'
sitemap.xml、RSSフィード、Open Graphなどで正しい絶対URLが生成されます
Sitemap (sitemap.xml)、RSSフィード (index.xml) はHugoが自動生成します
hugo server(開発時)では自動的にlocalhost:1313を使用するため、別途の処理は不要です

2. robots.txtの自動生成

ファイル: hugo/hugo.toml
内容: enableRobotsTXT = true
Hugoビルド時にrobots.txtが自動生成されます(すべてのクローラーを許可 + Sitemap URLを含む)

3. Schema.org構造化データ(JSON-LD)

ファイル: hugo/layouts/_default/single.html
記事ページ(type != "page")にBlogPostingのJSON-LDを挿入します
含まれる項目: headline、datePublished、dateModified、author、description、mainEntityOfPage
Google検索結果でリッチスニペット(作成者、日付など)を表示できます

4. og:image(代表画像) / Open Graph

ファイル: src/services/NotionExportService.mjs
Notion同期時にコンテンツ内の最初の画像を検出し、front matterのimagesフィールドに自動追加します
Open Graphメタタグは、Hugo内蔵テンプレート(_internal/opengraph.html)によって出力され、imagesをog:imageとして使用します

5. meta description / Twitter Card

ファイル: src/services/NotionExportService.mjs
Notionの「要約」プロパティをfront matterのdescriptionフィールドとして出力します
Hugo内蔵のopengraph/twitter_cardsテンプレートおよびbaseof.htmlのmeta descriptionで使用されます
Twitter Cardのメタタグは、Hugo内蔵テンプレート(_internal/twitter_cards.html)によって出力されます
その他のメタタグ(author、viewport)もテーマがデフォルトで提供します

6. Canonical URL

ファイル: hugo/layouts/_default/baseof.html
テーマ(m10c)のbaseof.htmlをオーバーライドして<link rel="canonical">タグを追加します
.Permalinkをcanonical URLとして使用します
多言語hreflangタグも一緒に含まれます(翻訳ページが存在する場合、alternate + x-defaultを出力)

7. Google Analytics(GA4)

テーマ(m10c)でデフォルト提供されます
Google Search Console認証時にGA連携で認証可能です

多言語SEOの主要要素

HTML lang属性

ページの言語を明示することで、検索エンジンとスクリーンリーダーに言語情報を提供します。

Hugo + GitHubでブログを作る

Tue, 10 Feb 2026 08:46:00 +0000

はじめに

技術関連の内容をEvernoteや個人ドキュメントに整理してきたが、Notionのウェブサイト機能を活用してブログとして運用しようと準備していた。

しかし、Notionはカスタマイズに制約があり、カスタムドメインの利用にも追加費用が発生するため、少し悩むことになった。

代案としてvelogに切り替えるか、Markdownで書き直してJekyllに移行するか検討した。

しかし、書きやすいNotionを諦めることはできなかった。結論はNotionで執筆し、静的ウェブサイトとしてデプロイすること!

目標

mdファイルで書かれたドキュメントをHugoでビルドし
GitHub Pagesでデプロイを自動化する

💡 構築環境

テスト環境: Mac

デプロイ環境: GitHub Actions

Hugoを選んだ理由

GitHub Starの数が多く、活発に更新されている
1000ページ以上をビルドする際にJekyllより速い

現在このブログは次のような流れで運用している。(ソース参考: )

Notionで執筆
→ Notion APIでMarkdownに変換

→ Hugoで静的サイトをビルド

→ GitHub Pagesにデプロイ

事前準備

Hugoテーマの選定

Hugo Themesでテーマをまず選んだ。

選んだテーマ: m10c

テーマ選定基準

SEO最適化機能をサポート
多言語サイト機能をサポート

m10cは一部機能が完全にはサポートされていないが、Hugoのレイアウトオーバーライドで補完できる。

Hugoのインストール

インストールドキュメント: Installation Guide

Hugoドキュメント: Documentation

Macの例

1# Hugoをインストール
2brew install hugo
3
4# インストール確認
5hugo --version

Hugoサイトの作成

プロジェクトの初期化

 1# 作業ディレクトリを作成
 2mkdir hugo && cd hugo
 3
 4# Hugoサイトを作成
 5hugo new site .
 6
 7# 生成結果を確認
 8tree
 9# .
10# ├── archetypes
11# │ └── default.md
12# ├── assets
13# ├── content
14# ├── data
15# ├── hugo.toml
16# ├── i18n
17# ├── layouts
18# ├── static
19# └── themes

テーマのインストール

Git submoduleを使ってテーマをインストールする。

GitHub Pagesでカスタムドメインを使う方法

Tue, 10 Feb 2026 07:34:00 +0000

概要

GitHub Pagesは基本的に https://{アカウント名}.github.io/{リポジトリ名}/ 形式のURLを提供します。

この記事ではカスタムドメインを接続する方法を説明します。

サブドメインを使用する

hugosample.plzhans.com のようなサブドメインを使用する場合です。

DNS設定

ドメインのDNS設定でCNAMEレコードを追加します。

設定例

Type: CNAME
Name: サブドメイン(例: hugosample)
Value: {アカウント名}.github.io

GitHub Pages設定

Repository → Settings → Pages → Custom domainでカスタムドメインを入力します。

入力例: hugosample.plzhans.com

apexドメインを使用する

plzhans.com のようにドメインのルートを使用する場合です。

apexドメインとは

www や blog のようなサブドメインを付けないドメイン自体を指します。ルートドメイン、ネイキッドドメイン(naked domain)、zone apexとも呼ばれます。

Apex: plzhans.com
サブドメイン: www.plzhans.com, blog.plzhans.com

💡 なぜapexにはCNAMEを使えないのか
サブドメインはCNAME一行で済みますが、apexはIPを直接記載するAレコードを使います。理由はDNS仕様にあります。

CNAMEレコードは同じ名前で他のレコードと共存できません。しかしapexには、そのゾーンを誰が管理しているかを示すSOAレコードとNSレコードが必ず存在しなければなりません。結局apexにCNAMEを入れると必須レコードと競合するため、標準に準拠したDNSでは登録自体が拒否されます。

GitHub Pagesがサブドメインとは異なり、apexに対してのみ4つのIPを案内しているのもこのためです。

CloudflareではapexにCNAMEが入ります

Cloudflareを使っていてapexにCNAMEを入れたら、そのまま動作したという場合があります。CNAME Flattening 機能のおかげです。

CloudflareがCNAMEの参照先を代わりに調べて最終的なIPアドレスを見つけ出し、外部からの問い合わせにはCNAMEではなくIPで応答します。設定画面にはCNAMEに見えますが、実際の応答はAレコードなので標準と競合しません。一部の状況ではデフォルトで動作し、そうでない場合は設定でオンにする必要があります。

参考: Cloudflare CNAME flattening

HTTPS TLS/SSL 無料 vs 有料証明書

Thu, 17 Mar 2022 16:48:00 +0900

概要

HTTPS通信のためにTLS/SSL証明書とドメインが必要です。

所有するドメインに対して発行され、クライアントは接続したドメインと証明書のドメインが一致するかを検証します。

この文書は、実務観点からドメイン別証明書発行方法を整理します。

理論よりも実務的な選択と実装に焦点を置きます。

SSL証明書発行および検証フロー

核心ポイント

CA機関の役割: サーバーの公開鍵を検証して署名し、信頼性を保証
発行業者の役割: サーバーとCA機関の間で証明書発行手順を仲介
OSの役割: CAルート証明書を事前に内蔵し、クライアントがサーバー証明書検証に使用
クライアントの役割: OSに内蔵されたCAルート証明書でサーバー証明書の署名を検証し、信頼性を確認

sequenceDiagram participant サーバー participant 発行業者 participant CA機関 participant OS participant クライアント %% 証明書発行段階 Note over サーバー,CA機関: 1. 証明書発行段階サーバー->>サーバー: 秘密鍵/公開鍵ペア生成サーバー->>発行業者: 証明書購入要求
(公開鍵 + ドメイン情報) 発行業者->>CA機関: CSR(証明書署名要求)伝達 CA機関->>CA機関: ドメイン所有権検証
(DNS/HTTP/Email方式) CA機関->>CA機関: CA秘密鍵でサーバー公開鍵署名 CA機関->>発行業者: 署名済みSSL証明書発行
(公開鍵 + CA署名 + ドメイン情報) 発行業者->>サーバー: 証明書伝達サーバー->>サーバー: 証明書と秘密鍵をサーバーにインストール CA機関->>OS: CAルート証明書事前登録
(ブラウザ/OS配布時に内蔵) %% HTTPS接続段階 Note over サーバー,クライアント: 2. HTTPS接続段階クライアント->>サーバー: HTTPSサイト接続要求
(Client Hello) サーバー->>クライアント: SSL証明書送信
(Server Hello) クライアント->>OS: CAルート証明書照会
(証明書検証用) OS->>クライアント: CAルート証明書返却クライアント->>クライアント: 証明書有効性検証
1) CAルート証明書で署名確認
2) ドメイン一致確認
3) 有効期間確認 alt 証明書検証成功クライアント->>クライアント: 安全なHTTPS接続表示 (🔒) Note over サーバー,クライアント: 以降暗号化通信開始 else 証明書検証失敗クライアント->>クライアント: セキュリティ警告表示
(信頼できない証明書) end

TLS/SSL証明書とは

ウェブでHTTPをHTTPSに転換するために必要なデジタル証明書です。サーバーで秘密鍵を生成し