every Tech Blog

株式会社エブリーのTech Blogです。

mamadays.tv から tomonite.com へドメインを変更しました

mamadays.tv から tomonite.com へ ドメインを変更しました

はじめに

この記事は、every Tech Blog Advent Calendar 2024(夏) の14日目の記事です。

株式会社エブリーでソフトウェアエンジニアをしている桝村です。

子育てメディア「MAMADAYS」は、2023年に「トモニテ」に名称変更しつつ、ロゴやアプリアイコンのデザインを刷新しました。

tomonite.com

トモニテのサービス名称変更については、以下の記事でも詳しく紹介しています。

tech.every.tv

また、サービス名称変更における対応の一つとして、Web メディアのドメインを mamadays.tv から tomonite.com へ変更しました。

本記事では、Web メディアのドメイン変更に伴う作業内容やそれによって得られた知見について紹介します。

この記事のゴールは、ドメイン変更を検討、または実施される方にとって、ドメイン変更の際に必要な作業や Google 検索結果への影響をできる限り抑えるためのポイント、およびドメイン変更で得た知見を共有することです。

前提

Web メディアのドメイン変更に際して、主な要件は以下の通りでした。

・ 新ドメインでサービスを公開できていること
・ 旧ドメインへのアクセスは、新ドメインへ 301 リダイレクトされること
・ ドメインで紐付ける各種サービスを新ドメインへ再登録すること (ex. Search Console, Ad Manager) 

要件を踏まえつつ、今後の Web メディアのサービス拡大を見据えて、今回は以下を意識・考慮しながらドメイン変更を進めることにしました。

・ 大きな不具合や遅延なくドメイン変更をやり遂げること
・ Google 検索結果への影響をできる限り抑えること

ちなみに、Google 検索結果への影響をできる限り抑えることにあたって、サイト移転に関する Google の公式ドキュメントがあったので、これに従って必要な作業を進めていきました。

developers.google.com

また、AWS リソースの管理には Terraform を使用しているため、今回のドメイン変更においても Terraform でリソースを追加・変更する作業を進めていきます。

ドメイン変更の準備

今回のドメイン変更の関係箇所をイメージしやすいように構成図にまとめました。

アーキテクチャ図
アーキテクチャ図

新ドメインの公開の準備

Amazon Route 53 により、新ドメインの公開の準備を行います。

  • 新ドメインの DNS を Route 53 に変更
    • Route 53 にて新ドメインのホストゾーンを作成し、お名前.com などのドメイン登録サービスにて Route 53 のネームサーバーを利用するように設定を変更
  • 新ドメインの公開の準備
    • Route 53 にて 新ドメイン用の A レコードを追加する Pull Request を作成・レビュー

A レコードの追加自体は、ドメイン変更の実施当日に行いますが、作業の正確性・一貫性の担保のため、事前に Terraform で PR 作成・レビューまで済ませておきます。

新ドメインへの通信を HTTPS で保護

ACM (AWS Certificate Manager) により、新ドメインへの通信を HTTPS で保護します。

  • 証明書のリクエスト
    • ACM から SSL/TLS 証明書をリクエスト
  • 証明書の検証
    • リクエストしたドメインに対して所有権を証明するため、DNS レコードを追加
  • 証明書のデプロイ
    • ACMから取得した証明書を ELB (Elastic Load Balancer) にデプロイ

また、Datadog などの監視ツールを使って証明書の有効期限が切れる前に通知を受け取る設定をしておきます。

旧ドメインから新ドメインへのリダイレクトの準備

AWS ALB (Application Load Balancer)により、旧ドメインから新ドメインへのリダイレクトの準備を行います。

AWS ALB のリスナールールにて、旧ドメイン mamadays.tv から新ドメイン tomonite.com へのステータスコード 301 でリダイレクトするルールを追加する Pull Request を作成・レビューします。

新ドメインへリダイレクトさせるルール
新ドメインへリダイレクトさせるルール

今回は、Aレコードと同様に 事前に Terraform で PR 作成・レビューまで済ませておきます。

resource "aws_alb_listener_rule" "mama_web_to_tomonite_web_rule" {
  listener_arn = aws_alb_listener.mamadays_ecs_lb_https.arn
  priority     = 4

  action {
    type = "redirect"

    redirect {
      host        = "tomonite.com"
      port        = "443"
      protocol    = "HTTPS"
      status_code = "HTTP_301"
    }
  }

  condition {
    host_header {
      values = ["mamadays.tv"]
    }
  }
}

Search Console にて、新ドメインのプロパティを作成

Web メディアのドメイン変更を実施した際は、SEO への影響が大きな懸念事項の一つです。

今回は Google Search Console を使って、新ドメインと旧ドメインでクローラーによるページのインデックスやユーザーのトラフィックがどのように変化するかを監視します。

それを実現すべく、予め新ドメインのプロパティを作成しておきます。

support.google.com

ただし、手順の一つであるサイトの所有権を確認は、DNS レコードの追加による方法で行う方針のため、新ドメインの公開後に対応します。

support.google.com

当日のドメイン変更の手順書を作成

作業の正確性・一貫性の担保や社内への共有のため、当日のドメイン変更の手順書を作成します。

# 1. 新ドメインの公開・リダイレクト
# 2. Search Console にて、元のサイトのアドレス変更の通知を送信
# 3. 新ドメインをベースとしたサイトマップを構築・配置・送信

※ 他にも細かい手順はありますが、ここではわかりやすさを重視して簡潔にまとめています。

ドメイン変更の実施

1. 新ドメインの公開・リダイレクト

「ドメイン変更の準備」にて事前に準備しておいた Aレコードの追加や ALB のリスナールールの追加を実施します。

今回は Terraform の PR をもとに terraform apply を実行するのみでした。

これでついに新ドメインが公開されました! 旧ドメインへのアクセスも新ドメインへリダイレクトされるようになります。

新ドメインを公開しました!

2. Search Console にて、元のサイトのアドレス変更の通知を送信

Google 検索の検索結果について旧ドメインから新ドメインへの移行を促すため、Search Console にて、元のサイトのアドレス変更の通知を送信しました。

support.google.com

新ドメイン側の Search Console にて以下の画面が表示されていると、アドレス変更が正常に処理されたことを示していると思われます。

アドレス変更の通知が送信完了
アドレス変更の通知が送信完了

3. 新ドメインをベースとしたサイトマップを構築・配置・送信

Google 検索エンジンに旧ドメインでなく新ドメインのページを認識してもらう必要があります。

そのために、新ドメインをベースとしたサイトマップを構築・配置した上で、Search Console にてサイトマップを送信しました。

support.google.com

全体を通して振り返り

トラフィック数は2ヶ月弱で変更前の水準に回復

ドメイン変更での大きな関心ごとの一つは、SEO への影響です。

新ドメインのページのインデックス登録は、ドメイン移行後の 1 ~ 2週間で完了しました。

また、Google 経由のトラフィック数は、ドメイン移行後の最初の2週間にはドメイン移行前の3分の2 ほどに減少しましたが、その後は徐々に回復し、ドメイン移行後の2ヶ月弱後にはドメイン移行前のトラフィックとほぼ同等の水準に戻りました!

目立った不具合なくドメイン変更を実施できたことや、Google 検索のドキュメントに従って丁寧に作業を進められたことも、この結果に寄与したのではないかと考えています。

ドメイン変更後のGoogle検索のトラフィックの推移
ドメイン変更後のGoogle検索のトラフィックの推移

※ ドメイン変更前の過去2ヶ月の平均

本番での作業を最小限にできた

当日の本番環境での作業が多かったり複雑であるほど、ヒューマンエラー等により作業の不具合や遅延が発生する可能性は高くなると思います。

今回はドメインの登録・リダイレクトを一つの CLI コマンドのみで実行できるようにする等、できるだけ本番環境での作業を最小限にでき、その結果目立った不具合などなく作業を完了できました。

事前に動作確認できる仕組みがあればよかった

今回開発工数の都合上開発環境での動作確認をメインに行いました。

しかし、理想としては本番環境との潜在的な差異を考慮してユーザーへの展開をする前に本番環境での動作確認も行うべきだったと考えています。

具体的には、特定の IP やユーザーエージェントからのアクセスのみ新ドメインへアクセスできるようにして動作確認を行うなどの方法が考えられます。

監視ツールの設定変更が漏れていた

ドメイン変更を実施したタイミングにて、監視ツール Datadog により WEB の死活監視に失敗したアラートが飛んでしまいました。

ページ自体は正常に見れており、原因としては 旧ドメインはリダイレクトさせたため、Datadog の死活監視の設定もステータスコード 200 に加えて 301 も許容するように変更する必要がありました。

本番環境での作業中にアラートが飛ぶことは、作業の遅延やミスに繋がる可能性があるので、監視ツールの設定も網羅的に見直すべきでした。

おわりに

今回は Web メディアのドメイン変更に伴う作業内容やそれによって得られた知見について紹介しました。

これから ドメイン変更を検討されている方、またはドメイン変更を実施される方にとって、参考になれば幸いです。