【SPA×MPA】検索エンジンには“店の外観（MPA）”を見せて、ユーザーには“店内（SPA）”を使ってもらう話

SPAはアプリケーションのように画面が滑らかに、サクサクと動き、ユーザーにとってはこれ以上ない最高の体験を提供できます。

しかし、Googleのクローラー（Googlebot）は、JavaScriptによってブラウザ側で動的にレンダリングされるSPAのきらびやかな中身を、ほとんど見ていません。

彼らが巡回時に評価しているのは、サーバーから返される「最初に読み込まれる静的HTML」、すなわち“店の外観”だけです。

どれだけ店内を豪華に、ユーザーフレンドリーに作り込んでも、外観（初期HTML）が空っぽであったり、どのページにアクセスしても全く同じ共通シェルだったりすれば、クローラー先生にはこうバッサリと切り捨てられます。

「この店、外から見る限り中身がありませんね。評価対象外（インデックス見送り）にします。」

SPAがサチコで「代替ページ」扱いにされたり、全くインデックスが増えなかったりする根本的な理由は、まさにこの“外観しか見ていない問題”に起因していました。

私は長らく、リッチUIを持つSPA側をサイトの正規な「本体」として検索エンジンに扱わせようと、必死の抵抗を試みていました。

• SPA側のURLを正規URL（Canonical）に指定していた
• sitemap.xml に SPA と MPA のURLを両方盛り込んでいた
• せっかく用意した MPA 側の Canonical が、SPA のURLを指すようにしていた

これは言うなれば、「中身が見えないクローラーに対して、なんとかして店内（SPA）を本尊として評価してくれ」と無茶なアピールを繰り返していたようなものです。

当然、Googlebotは店の奥に入ってくれないので、初期HTMLの状態だけを比較してこう判断します。

「URLは分かれているようだけど、受け取る外観はどれも全く同じ。重複コンテンツだからインデックスから弾いておきますね。」

そりゃあ、いくら待ってもインデックスが1ページも増えないわけです。

前回の記事で構築した「静的な紙の束（HTML）を量産する自作CMS」を経て、ようやく噛み合っていなかったギアを本来の姿へと修正しました。

• MPAのCanonical → 自分自身（articles/〜.html）のURLを指す
• SPAのCanonical → 対応する静的な MPA のURLを指す
• sitemap.xml → 完全に MPA のURLのみを記載する
• MPA（各記事や個別アルバム） → ページ固有の meta タグや OGP を1枚ずつ100%の密度で実装する

この構成により、Googlebotは「中身が詰まった個別の静的HTML」であるMPA側を正真正銘の「本物のURL」として認識し、スムーズにインデックスへ登録してくれます。

そして、検索流入からそのMPAにアクセスしてきた実際のユーザーには、裏側で違和感なくSPAのリッチなUI・再生プレイヤー環境へとシームレスに誘導する動線を敷けば良いのです。

「検索エンジンには外観（MPA）を見せ、人間には店内（SPA）を使ってもらう」。この逆転の発想による二重構造が成立して初めて、健全なSEOサイクルが回り始めました。

「近年のGoogleはJavaScriptを問題なく実行してレンダリングできる」という仕様を鵜呑みにして、SPA単体の構成でSEOを正面突破しようとするのは、個人開発の限られたリソースでは完全に悪手です。JSの実行を待つクロールはインデックスの優先度が著しく下がります。

それならば、最初から割り切って役割を分担させてしまうのが最適解です。

• ▪ 検索の玄関（集客窓口）：最速で評価される枯れた技術（MPA）に丸投げする
• ▪ 本命のユーザー体験（UX）：音楽を途切れさせないモダンなアプリ技術（SPA）で提供する

前回作った「HTML量産変換マシン」は、まさにこの強固で評価されやすい“玄関”を自動量産するための最高の武器だったというわけです。

SPAは最高のユーザー体験（UX）のために存在し、MPAは検索エンジンからの正当な評価（SEO）のために存在する。

検索エンジンにはMPAを本体だと思わせ、ユーザーにはSPAを本体として使い倒してもらう。

この二重構造を canonical と sitemap.xml の関係性で美しく制御することで、SPA×MPAのハイブリッド構成は初めて狙い通りの真価を発揮します。

これまでの長く暗いインデックス未登録との戦いが、同じようにSPA構成の個人開発サイトで首を傾げている開発者の参考になれば幸いです。