古いホームページのリニューアル｜やり直す判断基準と、検索順位を落とさない進め方古いホームページのリニューアル｜やり直す判断基準と、検索順位を落とさない進め方

「うちのホームページ、作ってからもう何年も触っていない」 「スマホで開くと崩れているけど、どこから直せばいいのか分からない」

リニューアルの相談は、たいていこのどちらかから始まります。見た目が古いのは分かっている。でも、作り直すほどなのか、作り直すなら何に気をつければいいのかが分からない。

迷って止まっている人は多いです。

リニューアルするかどうかの判断基準を、Googleなどの公式ドキュメントに書いてあることだけで並べました。後半は、作り直すときに一番の事故になりやすいURLの変更と301リダイレクトの話。例には、このサイト（stellarium.jp）で実際にやったURLの整理を使います。

古いホームページをリニューアルすべきか、4つの判断基準

見た目が古いこと自体は、作り直す理由として弱い。

判断は、次の4つで見ます。どれもブラウザで自分のサイトを開けば確かめられることです。

4つのうち、SSLだけは作り直さなくても直せます。サーバーの管理画面から証明書を入れられることが多いので、リニューアルの話とは切り分けて先に片づけたほうが早い。

残りの3つが重なっているなら、部分的に直すより作り直したほうが早い、というのが私の実感です。古い作りのサイトにスマホ対応を後から足そうとすると、ページごとに手を入れることになりがちだからです。

スマホで崩れるなら、検索の評価にも関わる

Googleが検索の登録と順位付けに使うのは、スマホ版のページ。モバイルファーストインデックスと呼ばれる仕組みです。

Google検索セントラルのドキュメントには、スマートフォン用のクローラーで取得したモバイル版のコンテンツを、登録と順位付けに使うと書かれています（出典はGoogle 検索セントラル「モバイル ファースト インデックスに関するおすすめの方法」）。

同じページには、気をつける点も並んでいます。

• 作り方はレスポンシブウェブデザイン（1つのHTMLを画面幅に合わせて並べ替える方法）が推奨されている
• スマホ版にもパソコン版と同じ主要なコンテンツを載せる。スマホ版にある内容だけが登録に使われる
• タイトルや説明文（メタディスクリプション）、構造化データもスマホ版とパソコン版でそろえる
• 主要なコンテンツを、タップしないと読み込まれない作りにしない

古いサイトでよく見るのは、パソコン版とは別にスマホ版を作ってあって、スマホ版だけ情報が少ないパターンです。この場合、Googleが見るのは少ないほう。

リニューアルするなら、レスポンシブで1つにまとめるのが無難です。

表示速度はCore Web Vitalsで測る。INPは2024年からの指標

「遅い気がする」は、数字にしてから話したほうがいい。

Googleは、ページの体験を測る指標としてCore Web Vitalsを出しています。いま使われている3つと、「良好」とされる目安はこうです（出典はweb.dev「ウェブに関する主な指標」）。

判定は、ページの読み込みの75パーセンタイルで、スマホとパソコンを分けて行います。INPは、以前のFID（最初の入力までの遅延）に代わって、2024年に正式な指標になりました。古い解説記事でFIDの話をしていたら、その部分は古い情報です。

順位への影響について、Googleは「Core Web Vitalsはランキングシステムで使われている」と書く一方で、ページの体験を表す単独のシグナルはなく、スコアが良いだけで上位になるわけではないとも書いています（出典はGoogle 検索セントラル「ページ エクスペリエンスについて」）。

速度だけを理由にリニューアルする必要はない、ということです。

改善候補として出ていたのは、使っていないCSSとJavaScriptの削減。作り直さなくても直せる種類の原因です。

速度が問い合わせや広告費にどう響くかは、広告のLPが遅いと広告費が上がる話に、LCPを12.6秒から4秒まで縮めたときの実測を書いています。

http:// のままのサイトは、ブラウザに警告が出る

2018年7月から、http:// で始まるサイトはChromeのアドレスバーに「保護されていない通信」と出るようになりました。Chrome 68で、HTTPのページがすべてこの表示の対象になっています（出典はGoogle 検索セントラル ブログ「HTTP を「保護されていない」と表示するようになります」）。

問い合わせフォームのあるページで、この表示が出ている状態を想像してください。

SSL化（https:// への切り替え）は、上に書いたとおりリニューアルを待たずにできます。切り替えたら、http:// のURLを https:// へリダイレクトしておく。このサイトも、http:// で開くと https:// へ恒久的なリダイレクトで飛ぶようになっています。

アクセシビリティはJIS X 8341-3とWCAGを基準にする

アクセシビリティは、目が見えにくい人や、マウスを使わずキーボードで操作する人も含めて、誰でもサイトを使える状態にすることです。

日本の規格はJIS X 8341-3:2016で、国際規格のISO/IEC 40500:2012と一致しており、中身はW3CのWCAG 2.0と同じです。解説はウェブアクセシビリティ基盤委員会（WAIC）が公開しています（出典はWAIC「JIS X 8341-3:2016 解説」）。

WCAGはその後も改訂されていて、2024年12月12日にはWCAG 2.2が勧告として公開されています（出典はW3C「WCAG 2.2」）。JISとWCAG 2.2の両方を目標にすることもでき、その場合はJISの対応度表記とWCAGの適合表明を区別して書くよう、WAICのQ&Aで案内されています（出典はWAIC「JIS X 8341-3:2016とWCAG 2.1、WCAG 2.2などを同時に対応することはできますか？」）。

全部の達成基準をいきなり満たすのは大変です。リニューアルで最低限見ておきたいのは、次のあたり。

• 画像に、内容を説明する代替テキスト（alt）が入っているか（WCAG 1.1.1）
• 本文の文字と背景のコントラスト比が4.5対1以上あるか。大きな文字は3対1以上（WCAG 1.4.3）
• フォームの入力欄にラベルがあるか（WCAG 3.3.2）
• 入力を間違えたとき、どこがどう違うかを文字で伝えているか（WCAG 3.3.1）

法律の話も1つ。改正障害者差別解消法が2024年4月1日に施行され、事業者による合理的配慮の提供が義務になりました（出典は内閣府「障害を理由とする差別の解消の推進」）。ウェブサイトで具体的に何が求められるかは、このページには書かれていません。それでも、古いサイトを作り直す機会に上のチェックくらいは入れておいて損はないはずです。

CMSは「誰が何を更新するか」で選ぶ

リニューアルで一番後悔が残りやすいのが、CMS（ページを管理画面から更新できる仕組み）選びです。

選ぶ前に、次の3つを紙に書き出してください。

1. 更新する人は誰か（社内の担当者か、制作会社か）
2. 何を更新するか（お知らせ、料金、施工事例、ブログなど）
3. どれくらいの頻度か（週1回か、年に数回か）

WordPressは自由度が高く、できないことが少ない。そのかわり、本体とプラグインの更新を続けることが前提です。WordPressの公式ドキュメントには、古いバージョンはセキュリティの更新が提供されないので常に最新にすること、プラグインも更新し、使っていないものは削除することが書かれています（出典はWordPress Developer Resources「Hardening WordPress」）。

更新作業を誰がやるのか決めないまま公開すると、数年後にまた「古いホームページ」に戻ります。

STUDIOのようなノーコードの制作サービスは、サーバーや更新作業を気にしなくていいかわりに、できることがサービスの仕様に左右されます。たとえばSTUDIOは、2026年6月に公開サイトの仕組みを新しい基盤に切り替えていて、古いプロジェクトは自分で切り替えるまで前の仕組みのまま動きます。切り替え前と後の違いはStudioのSEO対策にまとめてある。

このサイトはNext.jsで作り、記事はファイルに書いてGitで管理している。自分で書いて自分で公開する人には楽ですが、社内の担当者が管理画面から更新したい会社には向いていません。

大事なのは、道具の良し悪しより、更新する人に合っているかどうか。

リニューアルでURLが変わるなら、301リダイレクトが最優先

ここが、リニューアルで一番の事故になりやすいところです。

作り直すと、ページのURLが変わることがあります。たとえば /company.html が /about/ になる。何もしないと古いURLは「ページが見つかりません」になり、検索結果やほかのサイトのリンクから来た人がそこで止まります。

Googleのサイト移転のガイドに書かれている手順を、要点だけ抜き出すとこうなります（出典はGoogle 検索セントラル「URL の変更を伴うサイト移転」）。

1. 古いURLと新しいURLの対応表を作る。サイトマップ、サーバーのログ、アクセス解析から大事なURLを洗い出す
2. サーバー側の恒久的なリダイレクト（301または308）をかける。リダイレクトが何段にも連なるのは避ける
3. 新しいURLのサイトマップをSearch Consoleに送る
4. リダイレクトはできるだけ長く、一般的には少なくとも1年は残す

同じガイドには、移転のあいだ順位が一時的に揺れることがある、中規模のサイトでは新しいURLに置き換わるまで数週間以上かかることがある、とも書かれています。

ドメインごと変える場合は、Search Consoleのアドレス変更ツールも使います。http:// から https:// への切り替えや、www のあり・なしの変更には使いません。

このサイトでやったURLの整理

2026年9月19日、このブログのカテゴリーを組み直した。「マーケティング」というカテゴリーに、Shopify、採用、店舗集客の記事が混ざっていて、1つのまとまりになっていなかったからです。

記事のURL（/blog/記事名）はそのまま。変えたのはカテゴリーの一覧ページだけで、なくなった3つのカテゴリーのURLを、行き先のカテゴリーへ恒久的なリダイレクトでつなぎました。

設定は、Next.jsの設定ファイル（next.config.js）の redirects に、古いURLと新しいURL、恒久的かどうかを書くだけ。

実際に古いURLへアクセスして、返ってくる番号を確かめました。返ってきたのは308。301ではありません。Next.jsで「恒久的」を指定すると、308を返す作りになっているからです。Googleのガイドでは301と308はどちらもHTTPの恒久的なリダイレクトとして挙げられているので、このままで問題はない。

もう1つ、このサイトでは2025年3月にサービスページの場所を /ads-service から /services/ads-service のように移していて、そのときのリダイレクトも同じファイルにいまも残しています。1年以上たっても、消す理由がないので置いたまま。

リニューアルの進め方と、公開した日にやること

進め方は、大きく分けると次の順番です。

1. 今のサイトの数字を控える。Search Consoleで検索から人が来ているページと検索語、Googleアナリティクスで問い合わせにつながっているページ
2. 目的を決める。問い合わせを増やすのか、採用の応募を増やすのか
3. 残すページ、まとめるページ、消すページを決め、URLの対応表を作る
4. CMSを決め、デザインと実装に進む
5. 公開前に、スマホ表示、フォームの送信、リダイレクトを確かめる
6. 公開したら、サイトマップの送信と、アクセス解析の計測が動いているかの確認

1番を飛ばす人が多い。

作り直す前の数字がないと、リニューアルでよくなったのか悪くなったのか、あとで比べようがありません。Search Consoleの検索パフォーマンスは初期表示が過去3か月分なので、期間を広げて書き出しておくと安心です（出典はSearch Console ヘルプ「検索パフォーマンス レポート（検索結果）」）。

公開した日にやることは、チェックリストにしておきます。

• 古いURLをいくつか開いて、新しいURLに飛ぶか
• 飛んだ先がトップページではなく、対応するページになっているか
• 新しいサイトマップをSearch Consoleに送ったか
• 問い合わせフォームから自分宛てにテスト送信し、届くか
• Googleアナリティクスで、問い合わせの完了が記録されているか

引っ越しで郵便の転送届を出し忘れると、荷物は前の住所に届き続けます。URLの変更も同じで、リダイレクトは転送届にあたる。

公開した後に何を見て直していくかは、結果の出るホームページの作り方で、キーイベントの決め方から書いています。

リニューアルするか迷ったら、まず10分でできる確認から

作り直すかどうか、今日決めなくても大丈夫です。

その前に、スマホで自分のサイトを開く、アドレスが https:// か見る、PageSpeed Insightsでトップページを測る。この3つを10分でやってみてください。

どれも問題がなければ、作り直すより中身の更新を先にしたほうがいい。どれかが引っかかって、しかも社内で直せないなら、それがリニューアルを考えるタイミングです。

作り直すと決めたら、制作会社に最初に聞くのはデザインの好みではありません。「今のURLはどうなりますか」です。