DeskTechLabからTechLifeNoteへ移行した時にやったこと

DeskTechLab から TechLifeNote へ移行するにあたって、今回やった内容をまとめておくことにした。 コードの細かい変更点は別で整理するとして、この記事では移行全体の流れと、作業の考え方を中心に残している。

先に結論

今回の移行で大事だったのは、次の3点だった。

• 正規ドメインを techlifenote.com に決める
• 旧ドメイン desktechlab.com は残しつつ、新ドメインへ転送する
• 新旧URLのどれでアクセスしても、最終的に https://techlifenote.com に集約する

実際にやってみると、正規URLの考え方を最初に揃えることが重要だと感じた。

今回の移行方針

変更前と変更後はこう整理した。

ここで大事だったのは、www 付きや旧ドメインを中途半端に残さないことだった。 最終的には、次の形に統一している。

• https://techlifenote.com/ を正規URLにする
• https://www.techlifenote.com/ は正規URLへリダイレクト
• https://desktechlab.com/ は新ドメインへリダイレクト
• https://www.desktechlab.com/ も新ドメインへリダイレクト

この形にしておくと、見た目も分かりやすいし、あとで運用するときも迷いにくかった。

実際にやった作業の流れ

全体の流れはかなりシンプルだった。

1. 新ドメインを取得する
2. Cloudflare 側で新ドメインを接続する
3. Astro 側を新ドメイン前提に整える
4. www ありなしを正規URLへ揃える
5. 旧ドメインから新ドメインへ転送する
6. 実際に主要ページを開いて確認する

特に、旧ドメインからの転送を先にやるのではなく、新ドメイン側が正しく表示できる状態を作ってから 転送へ進むのが安心だった。

実際に変更した設定

Astro 側の変更

astro.config.mjs で以下を変更した。

export default defineConfig({
  site: 'https://techlifenote.com',  // 旧: 'https://desktechlab.com'
  // ...
});

この変更により、以下が新ドメイン基準で生成されるようになった。

• canonical URL（各ページの正規URL）
• sitemap.xml
• RSS フィード（今後追加予定）

robots.txt も新ドメインに更新した。

Sitemap: https://techlifenote.com/sitemap-index.xml
Host: https://techlifenote.com

Cloudflare 側の変更

Cloudflare の Redirect Rules で、以下の転送を設定した。すべて 301（恒久リダイレクト） を使用している。

1. www → apex（新ドメイン）

   • https://www.techlifenote.com/* → https://techlifenote.com/$1

2. 旧ドメイン → 新ドメイン

   • https://desktechlab.com/* → https://techlifenote.com/$1
   • https://www.desktechlab.com/* → https://techlifenote.com/$1

DNS は Cloudflare で管理しているため、新旧両方のドメインで A レコードと AAAA レコードを設定済み。HTTPS は Cloudflare の自動証明書で対応している。

作業中に意識したこと

今回の作業で意識したのは、変更点を増やしすぎないことだった。

たとえば、ドメイン変更と同時にURL構造まで変えたり、記事のslugまでまとめて変更したりすると、確認ポイントが一気に増える。 正直、そのやり方はリスクが高いと感じた。

そのため今回は、記事のURLパスは基本的に維持して、ドメインだけを入れ替える形 に寄せた。 この方針だと、旧URLの同じパスをそのまま新URLへ流せるので分かりやすい。

例としては、こんなイメージです。

• /posts/... は /posts/... のまま
• /tags/ は /tags/ のまま
• /about/ は /about/ のまま

見た目の変化は小さいが、この方があとから確認するときに分かりやすかった。

転送設定で確認したこと

転送設定を入れたあとに確認したのは、トップページだけではなかった。 むしろ、トップだけ見ても安心できないと思ったので、いくつかの種類のURLをまとめて確認した。

確認したのは主に次のページです。

• /
• /posts/...
• /tags/
• /about/

さらに、それぞれについて次のパターンを確認した。

• https://desktechlab.com/...
• https://www.desktechlab.com/...
• https://techlifenote.com/...
• https://www.techlifenote.com/...

この4系統で見ておくと、旧URLの取りこぼしや www のリダイレクト先ミスに気付きやすい。 実際、作業中はどれが正規で、どれが転送される側かを頭の中で混同しやすかったので、一覧で確認するのが役に立った。

機械的な確認

ブラウザ確認だけでなく、HTTPステータスコードも確認した。

# 旧ドメインから新ドメインへの転送確認
curl -I https://desktechlab.com/
# → 301 Moved Permanently
# → Location: https://techlifenote.com/

# www → apex の転送確認
curl -I https://www.techlifenote.com/
# → 301 Moved Permanently
# → Location: https://techlifenote.com/

301（恒久リダイレクト）が返ることで、検索エンジンに「ドメインが恒久的に変わった」と伝えられる。

また、各ページの canonical タグが新ドメインを指していることも確認した。ブラウザの開発者ツールで <link rel="canonical"> を見ると、すべて https://techlifenote.com/... になっていた。

今回の作業で整理できたこと

今回の移行で、運用上のルールも明確になった。

現在の正式な扱い

• 正規URLは https://techlifenote.com
• www.techlifenote.com は正規URLへ統一
• desktechlab.com は旧ドメインとして維持し、新ドメインへ転送

このあたりが揃うと、今後の運用で迷いにくい。

やっておいてよかったこと

今回の移行で、やっておいてよかったと感じたのは次の3つだった。

1. 正規URLを最初に決めたこと

www を使うのか、使わないのか。 旧ドメインをどう扱うのか。 このあたりを曖昧にしたまま進めると、設定がぶれやすい。

今回は最初に https://techlifenote.com を正規URLに決めたことで、その後の判断がしやすくなった。

2. 旧ドメインを残したこと

移行したからといって、旧ドメインをすぐ手放すのは怖いと思った。 過去記事へのリンクやブックマークが残っている可能性を考えると、旧ドメインはしばらく維持した方が安心だった。

3. 主要URLを実際に開いて確認したこと

設定画面で整っていても、実際にブラウザで開くと細かい違いに気付くことがある。 トップ、記事、タグ、About のように性格の違うURLを見ておくのは大切だった。

今回の作業で注意したいと思ったこと

逆に、注意したいと感じたのは次の点だった。

1. リダイレクトは一箇所で管理する

ドメイン単位の転送を Cloudflare の Redirect Rules で設定したため、repo 側（Astro の _redirects ファイルや middleware）には同じ転送を書かなかった。

両方で設定すると、どちらが効いているのか分かりにくくなる。また、変更時に両方を更新する必要が出てくるため、保守性も下がる。

今回の場合、Cloudflare 側でドメイン単位の転送を管理し、repo 側は新ドメインの挙動だけに集中する形にした。

2. 旧ドメインの文字列を全部消せばよいわけではない

旧サイトの案内文として残したいケースもある。 単純な一括置換ではなく、今の挙動に必要な箇所だけ更新する考え方の方が自然だった。

3. サイトマップの形式は環境によって異なる

今回の構成では sitemap-index.xml が生成されていた。最初は sitemap.xml を探したが見つからず、少し焦った。

Astro の @astrojs/sitemap は、ページ数が多い場合に自動的にインデックス形式（sitemap-index.xml）を使う。この形式では、複数の sitemap ファイル（sitemap-0.xml, sitemap-1.xml 等）に分割される。

環境や設定によっては sitemap.xml 単体の場合もあるので、ファイル名だけで決めつけず、実際に生成されたファイルを確認した方が確実だった。

まとめ

今回の移行で特に大事だったのは、次の3点です。

• 正規URLを最初に決める
• 旧ドメインは残して、新ドメインへ転送する
• 主要なURLを実際に開いて確認する

作業そのものはそこまで複雑ではないが、順番と整理の仕方でだいぶ分かりやすさが変わる。 ドメイン移行を検討している場合の参考になれば幸いです。