前回の記事では、自社サイトを LLMO・SEO・MEO の3つの物差しで診断した結果をお伝えしました。
18項目のうち、突出して低かったのは、SEO の表示速度の50点だけでした。
前回はそこまでで終わっていて、実際に手を動かして直す話は、今回に持ち越していました。
今回は、その診断結果を持って、実際に何を直したのか、という話をお伝えします。
8/21〜8/23にやったこと
大きく3つのことをやりました。
ここまでが、実際に直した3つの作業です。
ここから先は、直す作業を通じて見えてきた、この記事にしかない気づきを3つお伝えします。
診断の指摘は、直す順番とイコールではない
診断ツールは、リダイレクトが2回続けて発生している状態（2ホップ）を、機械的にチェックして減点します。
自社サイトにも、実はこのリダイレクトが残っています。
ただ、実際の中身を見ていくと、話はそこまで単純ではありませんでした。
検索エンジンや SNS 経由でやってくる訪問者は、canonical（正規の URL として指定されている https://www.… の形）にたどり着くので、リダイレクトを踏みません。
リダイレクトを踏むのは、URL を直接入力してやってくる、初回の訪問者だけです。
しかも HSTS（一度アクセスすると、次回からは自動的に安全な接続先へ切り替わる仕組み）が効いているので、2回目以降のアクセスでは、実質1ホップまで縮まります。
つまり、この指摘を直しても、効果があるのは数十ミリ秒から200ミリ秒程度の、ごく一部の訪問者に対してだけです。
一方で、診断では、キャッシュ設定に約3.05MB、画像の最適化に約2.2MBの削減余地があると示されていました（この見込みに対して、実際に WebP 化を終えてみると、トップページの画像だけで約23MBの削減になっていました。
詳しくはこの記事の最後で触れます）。
桁がまるで違います。
だから今回、リダイレクトの2ホップは後回しにしました。
診断ツールが指摘した順番どおりに直すのではなく、効果の大きさを見て順番を組み替える。
この判断そのものが、今回いちばんお伝えしたかったことです。
正直に書くと、後回しにしただけでなく、直そうとして直せなかったものもありました。
このリダイレクトは、契約しているレンタルサーバー の SSL の制約で、転送設定そのものを変更できませんでした。
空のフォルダに .htaccess を置いて回避できないかも試しましたが、その前の段階でサーバー側の301リダイレクトが先に返ってしまい、こちらの設定は効きませんでした。
診断の指摘を、必ずしも全部その場で直せるとは限らない、という実例です。
もう1つ、ついでに見つかった話も書いておきます。
meta description（検索結果に表示される説明文）が未設定と指摘されていたページが6件ありました。
実際に確認すると、この6件はすべて noindex（検索結果に出さない設定）のページで、そもそも直す必要のないものでした。
診断ツール自身が、noindex かどうかを見ずに指摘を出していた、という不具合でした。
こちらもあわせて、ツール側の判定を直しています。
レンタルサーバーによって、使える機能が違う
.htaccess にキャッシュ設定を書くとき、少し不安がありました。mod_expires というモジュールが、契約中のレンタルサーバーで使えるかどうか、事前に確認する手段がなかったからです。
レンタルサーバーは会社やプランによって、使えるモジュールが違います。
もし使えないモジュールの設定をそのまま書いてしまうと、最悪の場合、サイト全体が真っ白になって表示されなくなることもあります。
そこで、<IfModule mod_expires.c> というタグで、設定全体を囲みました。
これは「mod_expires があれば実行し、無ければこの中身ごと丸ごと無視する」という書き方です。
こうしておけば、仮にサーバー側にこのモジュールが入っていなくても、サイトが落ちることはありません。
結果としては、レンタルサーバーにはこのモジュールが入っていて、設定は問題なく動きました。
実測でも、画像やフォントに max-age=31536000 が正しく入っていることを確認できています。
ただ、これは今回たまたま入っていただけで、次に別のサーバーで同じ設定をするときも、同じように確認できるとは限りません。
「動くはず」で書くのではなく、「無くても壊れない」書き方をしてから試す、という順番を私は大事にしています。
直した効果が出るのは、次に来た人から
キャッシュ設定や WebP 化は、いずれも表示速度に関わる改善です。
ただ、表示速度のスコアの元になっている PageSpeed の実ユーザーデータ（CrUX）は、過去28日間にサイトを訪れた実際のユーザーの計測値をもとにしています。
つまり、8月22日・23日に直した内容が、この実ユーザーデータに反映されるのは、これから先、新しい訪問者が積み重なっていく1か月ほど先の話になります。
今日直したからといって、今日の数字が今日のうちに動くわけではありません。
もう1つ、確認するときに気をつけていることがあります。
シークレットウインドウは、閉じるとキャッシュがすべて消えてしまうので、キャッシュ設定の効果を確認するには向いていません。
通常のウインドウで、日を分けて確認する必要があります。
直した直後は、数字がどれくらい変わったのか、つい気になって何度も確認したくなるものだと思います。
ただ「直したのに数字が動かない」と焦って何度も測り直すより、「効果が出るのは次に来た人から」と理解した上で、必要な期間をあけて確認する方が、結果として正確です。
おまけ：削減幅は指摘の約9倍でした
8月21日の診断では、画像の削減余地は「約2,400KiB」という指摘でした。
トップページの画像だけで見ても、先ほどお伝えした26,617KB から3,251KB までの削減幅は、約23MB になります。
指摘の約9倍にあたります。
内訳を見ていくと、削減の大半は、昔からある画像ではありませんでした。
最近せっせと作っていた、ブログのアイキャッチ画像（PNG）が、削減幅のかなりの部分を占めていました。
診断は「削減できる余地がある」という方向は正しく示してくれますが、実際にどこまで減るか、その中身が何かは、手を動かしてみて初めて分かるものだと感じました。
8月23日時点の数字
今回直した内容のうち、title の修正や og:image の設定は、すぐに反映される種類の直しです。
一方、キャッシュ設定や WebP 化は、先ほどお伝えしたとおり、実ユーザーデータに反映されるまで時間がかかる種類の直しです。
そのため、前回の記事でお伝えした2026年8月23日時点の数字が、この記事を書いた8月下旬の時点でも、そのまま到達点でした。
LLMO は84点（A ランク）、SEO は72点（A ランク）、MEO は76点（A ランク）です。
18項目のうち、突出して低いのは表示速度50点のみで、この点は前回からまだ変わっていません。
これは、直していないからではなく、直した効果がまだ数字に出る段階まで来ていないためです。
次に測るとしたら、実ユーザーデータの収集期間を考えて、1か月ほど先になると見ています。
まとめ
前回は、診断してみてどう見えたか、という話をお伝えしました。
今回は、その診断結果を持って、実際に何を直したのか、という話をお伝えしました。
診断の指摘は、そのまま直す順番になるとは限らないこと。
レンタルサーバーによって使える機能が違うので、無くても壊れない書き方をしてから試す必要があること。
そして、直した効果が数字に出るのは、今日ではなく、次に来た人からだということ。
この3つが、実際に手を動かしてみて分かったことです。
診断で点数をつけて終わりではなく、その先にある「直す」という作業まで含めて、ようやく1つのサイクルになるのだと感じています。
ご自身のサイトも、無料で診断いたします
今回ご紹介したのは自社サイトの話でしたが、同じ診断は、ご希望の方のホームページにも無料でお使いいただけます。
LLMO・SEO・MEO の3つの視点から、どこが強くてどこが弱いのか、優先順位をつけてお伝えします。
診断だけでなく、どこから直すべきか、という順番のご相談も一緒に承っております。
もしご興味がございましたら、簡易的ではありますが、下記のフォームからお申し込みいただけます。
お名前、ホームページの URL など、いくつか質問がございますが、短時間でご入力いただけます。
コメント