シンドメインで取得したドメインをCloudflare DNSとPagesへ接続した記録

このサイトではドメインをシンドメインで取得し、DNSとホスティングはCloudflare DNSおよびCloudflare Pagesで管理している。ドメインの取得、権威DNSの委任、Pagesへのカスタムドメイン接続は似た操作に見えるが、担当する場所が異なる。切り分けておかないと、DNSの変更とAstroが出力する正規URLの変更を同じ作業として扱ってしまう。

接続で分けた責務

レジストラ側ではCloudflareが指定するネームサーバーへ委任する。Cloudflare側でゾーンが有効になった後、Pagesプロジェクトへ利用するカスタムドメインを追加する。ネームサーバー名やダッシュボードの文言は設定時点で変わり得るため、本記事では値を転載しない。設定時には各画面が表示する対象ドメインと案内値をそのまま照合する。

Cloudflareのドメイン一覧で、app-hacks.netがアクティブと表示されている確認例。これはゾーンの状態を示す画面であり、Pagesへの接続、DNSレコード、証明書、リダイレクトの設定内容を示すものではない。

HTTPSもPagesの公開状態と合わせて確認する。証明書の詳細や発行日時はこのリポジトリに記録されていないため、ここでは断定しない。ブラウザでHTTPSの正規URLが開けること、HTTPとwwwをどちらへ統一するかを実際の設定に照らして確認する。今回のサイトはhttps://app-hacks.netを正規URLの基準としている。

Astroの設定と公開URLをそろえる

DNSだけを接続しても、Astroの設定が別のホストを向くとcanonicalやSitemapがずれる。astro.config.mjsとサイト定数では同じ正規URLを使用している。

// astro.config.mjs
export default defineConfig({
  site: 'https://app-hacks.net',
  integrations: [sitemap()],
});

siteはSitemap integrationと絶対URL生成の基準になる。SEOヘッドはサイト定数からcanonicalを組み立て、public/robots.txtは同じホストのSitemapを指定している。設定後はトップ、記事、sitemap-index.xml、robots.txtのURLを並べ、ホスト・HTTPS・末尾スラッシュの方針が矛盾しないことを確認する。

失敗しやすい点と確認方法

未確認のIPアドレスを推測してDNSへ登録したり、旧ホストをcanonicalへ残したりしない。Pagesのカスタムドメイン設定で示される値を使い、反映を待ってから外部リンクを更新する。wwwの扱いもDNSだけで決めず、実際のリダイレクト、canonical、Sitemapを一組として確認するのが判断理由である。

公開前にはnpm run buildを実行し、生成HTMLのcanonicalとSitemapを確認する。公開後にはHTTPSで各URLを取得し、意図しないホストへ分散していないことを確認する。

接続作業を完了としてよいのは、DNSの画面で設定値が見える時点ではなく、利用者が正規URLへ到達し、サイト側のメタデータも同じURLを示す時点である。DNS、Pages、Astroの三か所は担当が異なるので、どれか一つだけを変更して完了としない。

記事やSNSなどへURLを案内する前にこの整合を取ることで、後からホストを置き換える範囲を小さくできる。

公式資料と関連記事

• Cloudflare公式: Custom domains — Pagesのカスタムドメイン設定の確認先。
• Astro公式: Configuration Reference — site設定を確認できる。
• Astroで構築するSEOに強いメタタグとOGP画像の共通コンポーネント設計 — canonicalを共通化する実装を扱う。