2025/11/26
[ 初回公開日:
2025/11/26
]
Studioでwwwあり/なしを正規化する:ムームードメイン+さくらレンタルサーバ構成の実例

はじめに:なぜStudio利用時のwwwあり/なし正規化が必要か
StudioでWebサイトを公開していると、意外と見落としやすいのが 「wwwあり/なしの正規化」 です。
技術的には別URLですが、多くのサイトではどちらか一方を「正」と決め、もう一方は301リダイレクトで統一しています。
ところが現時点のStudioは、このwwwあり/なし正規化をコントロールする機能が未提供 です。
Studioで独自ドメインを使った公開の全体像(ドメイン取得〜DNS〜TLS証明書発行まで)については、先にこちらの記事を確認しておくと流れがつかみやすいです。
→ 【Studio初心者ガイド】独自ドメインでのサイト公開の流れと設定手順
そのままにしておくと、例えば:
https://itplus.co.jp にアクセスすると「このサイトにアクセスできません」となる(うちのサイトは既に対応済みなのでそのURLクリックすると今はリダイレクトされます。)
検索エンジンから見たときに、wwwあり/なしが別サイト扱いになりやすい
といった問題が起こります。
この記事では、実際にIT+のサイトで行った
ドメイン管理:ムームードメイン
本番サイト:Studio(https://www.itplus.co.jp)
wwwなし(https://itplus.co.jp)の受け口&リダイレクト:さくらのレンタルサーバ
という構成をベースに、wwwあり/なしをきちんと正規化する具体的な手順 をまとめます。
あわせて、逆に「wwwなしをStudioで使いたい場合」の考え方 も紹介します。
- はじめに:なぜStudio利用時のwwwあり/なし正規化が必要か
- 今回のゴールと前提環境
- ドメイン管理(ムームードメイン)
- 本番サーバー(Studio)
- wwwなし受け+リダイレクト(さくらのレンタルサーバ)
- パターンA:wwwあり(https://www.itplus.co.jp)を正として統一する手順
- 全体像の整理
- ムームードメインでのDNS設定(Aレコードの分担)
- さくらレンタルサーバでのドメイン設定のポイント
- 無料SSL(Let’s Encrypt)の発行手順
- さくらに置く .htaccess の内容(完全サンプル)
- 動作確認チェックリスト
- ハマりポイント共有:最初に失敗した設定と、その原因
- 「wwwもさくらで使う」にチェックしてしまった
- 「他社サーバーで認証」フローに飛ばされた理由
- 解決の鍵は「役割の切り分け」だった
- パターンB:wwwなし(https://itplus.co.jp)をStudioで利用したい場合の考え方
- wwwなしを正とする場合のDNS構成
- さくらでwwwありだけを受けて、www.itplus.co.jp → itplus.co.jp にリダイレクト
- パターンAとの違いと、選び方の目安
- SEOとユーザー体験の観点からのまとめ
- StudioがURL正規化に未対応なときのリスク
- 今回の構成で得られるメリット
- 今後の運用で意識したいこと
- (補足)その他の方法
- Cloudflareの「Redirect Rules」や Cloudflare Pages を使う方法
今回のゴールと前提環境
ドメイン管理(ムームードメイン)
ドメイン取得・DNS管理は ムームードメイン
DNSレコードはムームードメイン側で編集し、Aレコードを
・Studio(wwwあり)
・さくらレンタルサーバー(wwwなし)
に分けて向けています。

本番サーバー(Studio)
本番のWebサイトは Studio 上で構築
正とする本番URLは https://www.itplus.co.jp(wwwあり)

wwwなし受け+リダイレクト(さくらのレンタルサーバ)
もともと別の用途で さくらのレンタルサーバ を契約しているため(他のレンタルサーバーでも全然問題ないです)
さくら側の役割はあくまでシンプルで、
・ルートドメイン itplus.co.jp だけを受ける
・無料SSL(Let’s Encrypt)を発行
・
.htaccessで https://www.itplus.co.jp へ301リダイレクト
という「SSL終端+リダイレクト専用ゲートウェイ」として利用します。

パターンA:wwwあり(https://www.itplus.co.jp)を正として統一する手順
全体像の整理
今回やりたいことは、次の状態をつくることです。
正とするURL:https://www.itplus.co.jp
それ以外(http://itplus.co.jp / https://itplus.co.jp など)は
すべて301リダイレクトで https://www.itplus.co.jp に統一
そのために、役割分担をこう決めます。
www.itplus.co.jp → Studio(本番サイト)
itplus.co.jp → さくらレンタルサーバ(SSL+リダイレクト専用)
ムームードメインでのDNS設定(Aレコードの分担)
ムームードメインのDNS設定は、概ね次のようになります。
サブドメイン空欄(@) / 種別 A / 内容:さくらのIP
例)210.224.185.232サブドメイン www / 種別 A / 内容:Studio指定IP
例)34.111.141.225
ポイントはただ一つで、
ルートドメイン(のAレコード) itplus.co.jp は さくらへ
www.itplus.co.jp は Studioへ
と、きちんと分けておくことです。
これにより、さくらから見ると「itplus.co.jp は自分のサーバーでホスティングしているドメイン」になり、通常の無料SSLフローが使えます。
(メール関連のMXやDKIMなど、他のレコードは既存の設定のままで問題ありません。)

さくらレンタルサーバでのドメイン設定のポイント
さくらのコントロールパネル →「ドメイン/SSL設定」で、itplus.co.jp を追加します。
「新しいドメインの追加」から itplus.co.jp を登録
「マルチドメインとして利用する」を選択
Web公開フォルダは任意(例:
~/www/itplus)
このとき、重要な設定が2つあります。
「www.が付与されたサブドメインも利用する」はチェックしない
ここにチェックを入れると、さくら側の前提は
「itplus.co.jp も www.itplus.co.jp も、このサーバで扱います」
になります。
しかしDNSでは www.itplus.co.jp のAレコードが StudioのIP を向いているため、
無料SSL発行時に
「wwwの実体は他社サーバーにある → 他社サーバーで認証してください」
というフローに飛ばされてしまいます。
今回の構成では www はStudioだけが持つ 前提なので、
「www.が付与されたサブドメインも利用する」にはチェックを入れない のが正解です。
www.転送設定は「転送しない」
www.itplus.co.jp に来るアクセスは、DNSレベルでStudioに行くため、
さくら側の「www.転送設定」はそもそも使われません。そのため、ここは 「転送しない」 を選んでおくのが安全です。

無料SSL(Let’s Encrypt)の発行手順
続いて、無料SSLを発行します。
「ドメイン/SSL設定」で itplus.co.jp の「SSL設定」を開く
「無料SSLの設定(Let’s Encrypt)」を選択
通常の無料SSL発行を選ぶ
※「他社サーバーで認証」になってしまったら基本設定が間違っているかも




Aレコードが itplus.co.jp → さくらIP になっていて、
かつ itplus.co.jp がマルチドメインとして追加済みであれば、
TXTレコードやファイル設置なしで、そのまま発行が通ります。
発行が完了すると、さくらから次のようなメールが届きます。
サーバ証明書種別:Let’s Encrypt
コモンネーム:itplus.co.jpすでにSSLサーバ証明書がお客様のレンタルサーバにインストールされました…

Let’s Encrypt自体は90日ごとの更新が必要ですが、
さくらの無料SSLは 自動更新 されるため、特別な運用作業は不要です。
さくらに置く .htaccess の内容(完全サンプル)
最後に、itplus.co.jp 用のWeb公開フォルダ(例:~/www/itplus)に、
以下の .htaccess を設置します。
RewriteEngine On
# http:// でもアクセスがあれば https://www へ統一
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^itplus\.co\.jp [NC]
RewriteRule ^(.*)$ https://www.itplus.co.jp/$1 [L,R=301]
この設定の意味はこうです。
RewriteCond %{HTTPS} off
→ HTTPでアクセスされた場合[OR]で次の条件と論理ORRewriteCond %{HTTP_HOST} ^itplus\.co\.jp [NC]
→ ホスト名が itplus.co.jp(wwwなし)の場合どちらかの条件に当てはまれば、
https://www.itplus.co.jp/…へ 301リダイレクト
つまり、
といったアクセスは、すべて
に統一されます。

動作確認チェックリスト
最後に、ブラウザで次の3つを確認します。
https://itplus.co.jp → アドレスバーが https://www.itplus.co.jp に変わるか
https://itplus.co.jp/ → 同じく https://www.itplus.co.jp に統一されるか
https://www.itplus.co.jp/ → https://www.itplus.co.jp に正規化されているか(Studio側の挙動)
すべて期待通りであれば、
SEO的にもユーザー体験としても「wwwあり一択」に正規化された状態 になっています。
ハマりポイント共有:最初に失敗した設定と、その原因
ここまで読むと「最初からその設定で良かったじゃないか」と思われるかもしれませんが、
実際にはいくつかハマりポイントがありました。
「wwwもさくらで使う」にチェックしてしまった
最初の失敗は、さくらのドメイン設定で
「www.が付与されたサブドメインも利用する」にチェックを入れてしまったこと
でした。
この設定をすると、さくらの解釈はこうなります。
「itplus.co.jp も www.itplus.co.jp も、このサーバで扱いますね」
一方でDNS側は、
itplus.co.jp → さくらIP
www.itplus.co.jp → StudioのIP
になっているため、設定と実体がズレた状態 になります。
「他社サーバーで認証」フローに飛ばされた理由
このズレが原因で、無料SSL発行時に
itplus.co.jp → さくらでホストしているのでOK
www.itplus.co.jp → AレコードがStudioのIPなので「他社サーバー」
と判定され、Let’s Encryptの
「他社サーバーで認証(DNSのTXTレコードやHTTPファイルで所有証明を行うモード)」
に飛ばされてしまいました。

そこからさらに、
TXTレコードのホスト名が正しいか
CAAレコードでLet’s Encryptが禁止されていないか
レートリミットに引っかかっていないか
などを疑いはじめてしまい、かなり遠回り
することになりました。
解決の鍵は「役割の切り分け」だった
振り返ってみると、解決の鍵はシンプルで、
さくらに扱わせるのはルートドメインだけ
www はStudioだけが扱う
という「役割の切り分け」を明確にすることでした。
そのために、
さくら側では「www.が付与されたサブドメインも利用する」をオフにする
DNSでは itplus.co.jp → さくらIP / www.itplus.co.jp → Studio IP を徹底する
という2点を押さえれば、
無料SSLは通常モードでスムーズに発行され、
あとは .htaccess を1ファイル置くだけで、きれいに正規化できることがわかりました。
※まぁ単純に私がちゃんと考えずに適当に設定しただけで、普通に設定していれば素直にSSLは通ったんですがww
パターンB:wwwなし(https://itplus.co.jp)をStudioで利用したい場合の考え方
ここまで紹介したのは、
wwwあり(https://www.itplus.co.jp)を正とする構成
でしたが、逆に
wwwなし(https://itplus.co.jp)をStudioで本番URLにしたい
というケースもあります。この場合の考え方だけ整理しておきます。
wwwなしを正とする場合のDNS構成
wwwなしを正とする場合は、DNSをこう考えます。
itplus.co.jp → Studio指定IP(本番サイト)
www.itplus.co.jp → さくらレンタルサーバIP(リダイレクト用)
つまり、パターンAとは逆に、
ルートドメインは Studio に直結
www の方を、さくらでSSL+リダイレクト専用として扱う
という構成になります。
さくらでwwwありだけを受けて、www.itplus.co.jp → itplus.co.jp にリダイレクト
さくら側では、おおまかに次のような手順です。
ドメイン追加時に www.itplus.co.jp(サブドメイン付き)をマルチドメインとして登録
www.itplus.co.jp 用に無料SSL(Let’s Encrypt)を発行
Web公開フォルダに
.htaccessを置き、
https://itplus.co.jp(wwwなし)に301リダイレクト
発想としてはパターンAと同じで、
どちらのドメインをStudioに向けるか
どちらのドメインをさくらで受けるか
を入れ替えただけです。
パターンAとの違いと、選び方の目安
すでに wwwありのURLが世の中に広く出回っている 場合
→ パターンA(wwwありを正とする)が自然新規サイトで、シンプルにドメインだけで見せたい(https://example.com)場合
→ パターンB(wwwなしを正とする)も選択肢
どちらを選んでも重要なのは、
どちらか一方を「正」と決めること
もう一方は SSL付きで301リダイレクトすること
この2点です。
SEOとユーザー体験の観点からのまとめ
StudioがURL正規化に未対応なときのリスク
Studio自体はSEOフレンドリーなCMSですが、
wwwあり/なしの正規化機能については、まだ実装予定が未定の状態です。
このまま何もしていないと、
https://itplus.co.jp で「このサイトにアクセスできません」と表示される
検索エンジンに、wwwあり/なしが別サイトとしてインデックスされる可能性がある
といったリスクがあります。

今回の構成で得られるメリット
この記事で紹介したように、
ドメイン管理:ムームードメイン
本番サイト:Studio
片方のドメインだけをさくらで受けて、SSL+301リダイレクトを担当させる
という構成を取ることで、
ユーザーは どのURLでアクセスしても最終的に同じURLにたどり着く
検索エンジンにも 一貫した正規URLを示せる
さくらの無料SSLは自動更新なので、運用コストも低い
というメリットが得られます。
なお、本記事では「wwwあり/なし」をサーバーレベルで正規化する方法を扱いましたが、サイト内の特定ページだけ別URLに移動したい場合には、Studio標準の301リダイレクト機能を使うのが便利です。
→ 【Studio初心者ガイド】リダイレクト機能|設定、編集、削除方法
今後の運用で意識したいこと
サイト内リンクや外部資料で記載するURLは、
正と決めた方(今回のケースでは https://www.itplus.co.jp)に統一するさくらのコントロールパネルで、SSLステータスにエラーが出ていないかを
ときどき確認する構成変更(DNSやホスティングの移動)を行うときは、
「どのドメインをStudioに向けるか」「どのドメインをさくらで受けるか」を
まず紙に書き出して?整理してから作業するw
Studio側にURL正規化機能が入るまでは、
ムームードメイン+さくらレンタルサーバを組み合わせて“片側だけゲートウェイにする” という今回のやり方は、
SEOとユーザー体験の両方を現実的なコストで整える一つの解決策になると感じています。
(補足)その他の方法
Cloudflareの「Redirect Rules」や Cloudflare Pages を使う方法
CloudflareなどのCDNサービスを使って、wwwあり/なしのリダイレクトを行う方法もあります。たとえば ドメインのDNSをCloudflareに移管したうえで、Cloudflare の Redirect Rules だけで wwwあり/なしのリダイレクトを完結させることもできますし、Cloudflare Pages 上に簡易サイトを置いて _redirects で転送させる構成を取ることもできます(こちらはDNS移管をせず、既存DNSからPagesにCNAMEで向ける運用も可能です)。今後そのドメインでサブドメインを増やしたり、静的サイトやLPを複数ホストしたりする予定がある場合は、DNSごとCloudflareに寄せておくとリダイレクトやルーティングを一元管理しやすいというメリットもあります。ただし、私のような非エンジニアの方には設定画面や用語がややわかりづらいため、本記事では詳しい手順の紹介は割愛します。
この記事を書いた人




























