Cloudflare PagesのAstroサイトを独自ドメインへ移行したときに見直した設定

3分英語物語は、Cloudflare Pagesで公開しているAstro製のサイトです。

公開当初はCloudflare Pagesが発行する three-min-english-story.pages.dev を使っていましたが、その後 three-min-english.okunoapps.com という独自サブドメインへ移行しました。

Cloudflare Pagesでは管理画面からカスタムドメインを追加できます。ただ、実際に移行してみると、変更する場所はCloudflare側のドメイン設定だけではありませんでした。

Astroの設定、canonical、sitemap、robots.txt、Search Console、旧URLからのリダイレクトまで、新しいURLを基準にそろえる必要があります。

この記事では、3分英語物語で実際に見直した箇所を整理します。

カスタムドメインを追加しただけでは移行は終わらない

Cloudflare Pages側で独自ドメインを設定し、新しいURLでサイトが表示できれば、表面上は移行できたように見えます。

ただ、サイト内部には公開URLを前提にしている設定が残っています。

3分英語物語の場合、特に確認が必要だったのは次の部分でした。

Astroの site
canonical URL
OGPのURL
sitemap
robots.txt
Google Search Console
旧 pages.dev からの301リダイレクト

新しいドメインでページが開くことと、サイト全体が新しいURLを正規URLとして扱っていることは別です。

Astroの `site` を新しいURLへ変更する

Astroでは astro.config.mjs の site に、本番環境のURLを設定できます。

3分英語物語では現在、次のように設定しています。

export default defineConfig({
  site: 'https://three-min-english.okunoapps.com',
  integrations: [
    sitemap({
      filter: (page) =>
        !page.endsWith('/favorites/') && !page.includes('/oldest/'),
    }),
  ],
});

Astro公式ドキュメントでも、site は最終的な公開URLとして扱われ、sitemapやcanonical URLの生成に利用される設定です。

このサイトではSEO用の共通コンポーネントでも Astro.site を参照しています。

const canonicalUrl = canonical && Astro.site
  ? new URL(Astro.url.pathname, Astro.site).toString()
  : undefined;

つまり、Cloudflare側だけ新ドメインに変更して site が古いままだと、ページは新しいドメインで表示されていても、canonicalだけ旧URLを指す状態になり得ます。

3分英語物語ではOGPの og:url や画像URLも Astro.site を基準にしているため、ドメイン移行時にはここを最初に確認しました。

sitemapとrobots.txtも新しいドメインへそろえる

3分英語物語では @astrojs/sitemap を使ってsitemapを生成しています。

site を新しいURLへ変更すると、生成されるsitemapも新ドメインを基準にできます。

現在は次のURLで公開しています。

https://three-min-english.okunoapps.com/sitemap-index.xml
https://three-min-english.okunoapps.com/sitemap-0.xml

一方、robots.txt は静的ファイルなので、こちらに古いURLが残っていないかも別途確認しました。

現在の指定は次の形です。

User-agent: *
Allow: /

Sitemap: https://three-min-english.okunoapps.com/sitemap-index.xml

Astro側の設定だけ直しても、静的な robots.txt に旧ドメインが残っていれば、検索エンジンへ古いsitemapを案内し続けることになります。

ドメイン名をコード内に直接書いているファイルがある場合は、移行時にまとめて検索しておく方が安全です。

Search Consoleでも新しいURLのsitemapを確認する

ドメインを変えた後は、Google Search Console側でも新しいサイトの状態を確認しました。

3分英語物語ではSearch Consoleの所有権確認用HTMLファイルを public/ に置いています。

移行後は、新しい独自サブドメイン側でsitemapを読み込ませ、sitemap-index.xml が正常に取得されることを確認しました。

サイト側でsitemapを新しくしても、Search Consoleで旧URLだけを見続けていると、移行後のクロール状況を把握しにくくなります。

少なくとも、新しいドメインのsitemapが取得できていることと、主要ページが新しいURLで認識されていることは確認しておいた方がよい部分です。

旧pages.devは301で新しいURLへ送る

Cloudflare Pagesでは、独自ドメインを設定しても、元の *.pages.dev のURLが自動的に消えるわけではありません。

そのまま両方のURLで同じ内容へアクセスできる状態にすると、旧URLも残り続けます。

3分英語物語では、旧URLから新しい独自サブドメインへの301リダイレクトを維持しています。

重要なのは、トップページへまとめて飛ばすのではなく、できるだけ同じパスへ対応させることです。

旧:
https://three-min-english-story.pages.dev/stories/example/

新:
https://three-min-english.okunoapps.com/stories/example/

Cloudflareの公式ドキュメントでも、*.pages.dev からカスタムドメインへ301で転送し、パスやクエリ文字列を維持する方法が案内されています。

Googleのサイト移行ガイドでも、URL変更を伴う移行では旧URLから新URLへの恒久的なリダイレクトと、新しいURLを含むsitemapへの更新が重要な項目として挙げられています。

相対URL中心なら直す箇所を減らせる

ドメイン移行時にすべてのリンクを書き換える必要があるかは、普段のURLの持ち方にも左右されます。

たとえばサイト内リンクを、

<a href="/stories/">物語一覧</a>

のような相対URLで書いていれば、ホスト名が変わってもそのまま新しいドメイン上で動きます。

一方で、

https://three-min-english-story.pages.dev/stories/

のような絶対URLをコードやMarkdownへ直接書いている場合は、個別の置き換えが必要です。

ドメイン移行を予定していなくても、サイト内部のリンクを必要以上に絶対URLで固定しない構成にしておくと、後から公開先を変えるときの修正範囲を小さくできます。

移行後に確認する項目

今回のような構成なら、独自ドメインを追加した後に少なくとも次を確認します。

新しいドメインでページが表示できる
astro.config.mjs の site が新しいURLになっている
canonicalと og:url が新しいURLを指している
sitemap内のURLが新しいドメインになっている
robots.txt のsitemap URLが新しくなっている
Search Consoleで新しいsitemapを取得できる
旧 pages.dev の各URLが対応する新URLへ301で移動する

ブラウザでトップページが開くだけでは、このうち1つ目しか確認できません。

ドメイン移行では、表示先を変える作業と、検索エンジンやサイト内部が参照する正規URLを変える作業を分けて考えると確認漏れを減らせます。