WordPressのリニューアルとSSL化を同時に実施する際のURL設計とリダイレクト：運営堂サイトリニューアル (3)

運営堂さんのサイトリニューアルを振り返るシリーズ、3つ目は「URL設計とリダイレクト」です。運営堂さんのサイトは有効な記事数が2200ページ。リニューアルに合わせてURLの変更もするし、同時にSSL化も実施します。ここでしくじると、コツコツと積み上げてきたページの評価は暴落…。森野さんから白い目で見られ、私にとっても死活問題になりかねません…！　というのは半分冗談ですが、起こってしまうと笑えないのは確かです。そうならないために実施した、URL設計とリダイレクトについてまとめたいと思います。

URL設計の方針と課題

URL設計の方針

運営堂さんのサイトは初期構築からだいぶ月日が経っていて、長年の運用の中でURLが日本語になっていたり、URLの構造がコンテンツと一致していない部分が多くありました。リニューアルの目的の一つに常時SSL化もあるので、結局全てのURLが変更になります。URL構造を再設計できるいいタイミングですが、1点、これまでに培った「いいね」は出来るだけ失いたくない、という要望もあり、まとめると次のような方針になりました。

URL構造の変更に伴う課題

例えば静的なページで構成されるサイトであれば、特に制約もなくゼロベースで設計ができますが、今回はWordPressが前提です。URL構造を再設計するうえで、システムの仕様は無視できません。カスタマイズ可能なのか、そのインパクトはどれほどなのか。メリットとデメリットを天秤にかけて判断する必要があります。
また、2200のURLが変わるので、いかに効率的かつ確実なリダイレクト処理をするか、という点も大きなポイントでした。

URL設計とシステムの仕様

WordPressのようなシステムを前提としたサイト構築の場合、URL設計の時点である程度システムの仕様を想定しながら進めます。今回は、対象のコンテンツがWordPress上どのポストタイプで設定されるつもりなのかを設計書に記載して、プログラマに共有しました。下図は実際の設計書の一部ですが、赤枠がその欄です。

このポストタイプはあくまで私の想定で、同じURLが実現できるのであれば、別の方法で構わないのでその点はプログラマの意見を優先します。
私がWordPress案件を設計する場合、標準の仕様と異なるURLを指定する場合が多いので、設計したURLの実現性の可否を確認してもらうための手がかりとして記載しています。

設計したURLがWordPressの仕様と異なる点

例えば今回、メインのブログ以外の投稿系のコンテンツ「ズバッと解決GA」というコンテンツに対し「カスタム投稿タイプ」を使って、次のようなURL構造を指定しました。

ページ	URL
トップ	/ga-solution/
カテゴリ一覧	/ga-solution/words/ ★
個別記事	/ga-solution/post-345/

★の付いたURLは、標準の仕様であれば/ga_category/wordsのようになり、/ga-solution/がなくなってしまいます。これはプラグインを入れることにより、/ga-solution/ga_category/wordsになるのですが、一般的な感覚では「この/ga_category/って何？階層一個多くない？」となるので、グランフェアズでは多くの場合、この/ga_category/を取った形で実装をします。

ただしこれは、WordPressのコアに触れるカスタマイズです。「できると聞いたからやってみて」ということではなく、設計者もプログラマもデメリットに向き合った上で採用は決めないといけない部分です。

これについては、野村さんが詳しく記事にされているので、ぜひこちらもご覧ください。

今回特別にトリッキーだったところ

通常であれば、サイト全体を上のような構造で設計していくのですが、今回は1点、さらにトリッキーな構造がありました。それは、サイトオーナーである森野さんの鶴の一声に端を発しています。

「いいね」を継承したいのでお願いします。

メインの投稿コンテンツ「運営堂ブログ」はリニューアル前、次のようなURL構造でした。

ページ	URL
トップ	/bloglist
カテゴリ一覧	/category/google-analytics
個別記事	/14202.php

ブログ自体がルート直下で展開されていて、「いいね」の対象である個別記事は、/{%post-id%}.phpという形です。「運営堂ブログ」はメインではあるものの、サイト内の一つのコンテンツ群。URL構造としては適していないので、/blog/という階層を持たせる設計にしました。この流れだと、個別記事は/blog/14202.phpとするのが一般的です。でも今回はできません。「いいね」を継承するためには、プロトコル（http→https）以外のURLは変更できませんから…！
ということで、次のような設計になりました。

ページ	URL
トップ	/blog/
カテゴリ一覧	/blog/google-analytics/
個別記事	/14202.php

ふふふ…トリッキー。でもちゃんと実装できてますから。野村さんすごいよね。

システムの仕様を変えてまで、なぜURLにこだわるのか

1つのサイトやサービスにおいて、URLは資産だと私は思っています。どんなサイトも、5年経てばリニューアルします。見た目（デザイン）やシステムは毎回変わるけれど、URLの価値は蓄積されて、サイトオーナーの資産として残っていきます。この資産価値を落とさないためにも、URLは安易に変えるべきではないし、もし変えるのであれば、将来的に変えなくていいような、恒久性・継続性のあるURLにした方がいい、と思うのです。

次のリニューアルで選ぶシステムは何になるか分からない。だから可能であれば、システムに依存しないURLにしておきたい、というのが私の思いです。
でも、いつでもそうするわけではありません。知らないシステムではやらないし、継続した運用業務を請け負わない場合はやりません。

URL設計とリダイレクト

リニューアルにおけるURL設計とリダイレクトは一心同体です。「URLをこう変えると、リダイレクトはこうしないとな」ということを常に考えながらURLを作っていきます。今回は数とパターンが多いので、設計書に含めて整理しました。

リダイレクトの対象となるURL（今回はほぼ全て）を、次の3つの処理パターンに分類しています。

分類	処理パターン
個別 (日本語)	日本語URLをアルファベットに変更したもの。個別対応が必要
個別 (変更)	アルファベットだが名称を変更したもの。個別対応が必要
正規表現	変更したが、規則性があり一括処理できるもの

日本語からの変更は 1：1 でリダイレクトするしかありませんが、なるべく設定する数を減らしたい。ポイントは分類の3つ目で、正規表現でまとめて指定できる場合はそちらを優先し、不必要な変更は加えないという点です。

下図は運営堂サイトの「運営堂ブログ」の例です。赤い文字が今回変更した部分で、青い文字は変更していません。このような規則性を持たせることで、リダイレクト処理はたったの1行で済みます。エコですね。

たまに「そのURL、意味的にその英単語は合ってないかも…」というのに遭遇しますよね。その場合も、ぐっとこらえて華麗にスルーです。（もちろん、設定する全体数によりますが）

大量の処理コードはエクセルで作る

今回、運営堂さんのサイトには日本語のURLが140ありました。それだけで140行リダイレクト処理のコードを書くわけですが、今回書いたリダイレクトの総数はなんと383行ありました。今までで一番多かったです。　┐(´д｀)┌ﾔﾚﾔﾚ

そんな大量の類似コードをコピペで複製・手入力しているとどこかでミスするので、エクセルを使ってコードを量産しています。

上の図は、/gainfo/{日本語URL}を/ga-solution/post-{記事ID}/にリダイレクトさせるために使ったエクセルの一部です。C列の記事IDは、新サーバに記事データを移植した後のIDです。D列でpost-とC列を結合し、A列とD列の値を使ってリダイレクト用のコードをE列に出力しています。
E列に設定してある関数は次のようなもの。

="RewriteRule ^gainfo/"&$A2&"$ /ga-solution/"&$D2&"/ [R=301,L]"

A列とD列に値が入れば、E列にばばっとコードが表示されます。
後は、E列を上から下まで全部一気にコピーして、.htaccessにペーストするだけ。一行ずつ書いてたら本当に気が遠くなりますが、これだと正確だしかなりの時短になります。エコですねー。

新旧URLのリダイレクトは、.htaccessに統一する

少し本題から離れますが、URLのリダイレクトはWordPress（PHP）でも出来ます。きちんと301になります。リダイレクト用のプラグインもあるので、そちらの方が手軽かもしれません。でも、URLのリダイレクトはWordPress（PHP）側で処理しない方がいいです。理由は次の2点

運用においては2番目が問題になることが多いです。「なぜかリダイレクトが3回もかかっている？ようで解析がきちんとできない…」といった事をよく聞きますが、そうなると「リダイレクトの処理をプラグインで設定をしているのか、内部のPHPファイルに記述しているのか、その両方なのか、あるいは .htaccess と干渉しているのか…」と原因追及もかなり手こずります。
なので、URLのリダイレクトは .htaccess に統一しましょう。

その結果

長くなりました…。やっと終わりです。
いろいろとこれらの対策を実施したところ、リニューアル後に森野さんから（意図しない）404はゼロ、順位変動なしという結果をご報告いただきました。ぃよっっしゃあああ！です。

ここで記載したURL設計やリダイレクトの対応は最近に始まった事ではなく、SEOという言葉が出来る前から、前職で上場企業のBtoB企業サイトのリニューアルを多数担当させていただいていた時から、手法は違えど取り組んできたことばかりです。なのでWordPressだからとか常時SSL化だからとかではなく、どんな場面でも大切なことではないかなと思います。

「リニューアルをすると必ず検索順位は下がる」とよく聞きますが、私はこの18年間、リニューアルで順位を下げたことは一回もありません。これはちょっとした自慢です。　…こんなオチですみません。

---

プロジェクトの全体像については、森野さんがシリーズで記事にしてくれてるので、ぜひこちらもご覧ください。