2022年初頭、あるクライアントがやってきました。中規模のファッションブランドで、月間オーガニックセッション数は約40,000、ドメインレーティングは良好、Shopifyを4年間使用していました。彼らはdev agencyを雇ってNext.jsとShopifyのStorefront APIで一から構築し直していたのです。新しいサイトは見た目も素晴らしく、本当に速かったです。そしてライブになってから6週間以内に、オーガニックトラフィックの38%を失ってしまいました。
重要なポイント：Headless Shopifyへの移行は、すべての移行と同じ方法でランキングを保護します。つまり、完全なリダイレクトマップ、バイト単位で同一のメタデータ転送、および新しいビルドに対するCore Web Vitalsの予算配分です。
リダイレクト監査を実施していなかった。サイトマップが壊れていた。カノニカルタグが間違った環境を指していた。これは大災害で、事態が安定するまで約 6 万ポンドの売上を失った。
Headless移行は純粋な技術的な勝利に見える動きの一つです。レンダリングが速く、フロントエンドが分離され、デザインの自由度が完全です。しかし、SEOを後付けとして扱えば、ひどい代償を払うことになります。Seahawk Mediaで12,000以上のサイトに関わってきた経験から、このパターンが何度も繰り返されるのを見てきたので、きちんと書き留めておきたいと思いました。
---
ヘッドレス Shopify が最初の場所で SEO を壊す理由
Shopifyの標準テーマアーキテクチャは、あなたが気づかないうちにSEOの重い処理の多くを肩代わりしています。Canonicalタグは自動生成されます。/sitemap.xmlにあるsitemap.xmlは自動的に保守されます。商品の構造化データはLiquidを通じてあらかじめ組み込まれています。ページネーションはShopifyが静かにバックグラウンドで管理するrel="next"およびrel="prev"の慣例を使用しています。
Headlessに移行した瞬間、通常はNext.js、Nuxt、Remix、SvelteKitのようなフレームワークでShopify Storefront APIからデータを引き出すことになりますが、それはすべてあなたの責任になります。すべてのcanonical、すべてのhreflang、すべての構造化データブロック、すべてのリダイレクト。もう無料では提供されません。
そして、ここが肝心な点です。ほとんどのdev チームはReactが得意だから雇われます。ファセット化されたナビゲーションクロールトラップがどのように見えるかを知っているからではなく。
私が常に見かける3つの失敗パターン
- ステージング環境のURLが本番インデックスに漏れる。dev チームがstaging.mybrand.comまたはVercelプレビューURL上で構築し、適切にnoindexを指定し忘れて、Googleがクロールし、突然ライブサイトと競合する重複コンテンツが発生します。
- URL再構築時の破損または欠落したリダイレクト。ヘッドレスプロジェクトはほぼ常にURLの変更を伴います。/collections/mens-shirtsが/category/shirtsまたはそれ以上に悪いものになります。301が配置されていないと、すべてのインバウンドリンクとGoogleインデックス登録済みのURLが404を返します。
- クライアント側レンダリングが低い。ヘッドレスフロントエンドがSSRやSSGなしで純粋にクライアント側で商品コンテンツをレンダリングしている場合、GooglebotがコンテンツをY確実に取得していない可能性があります。GoogleはJavaScriptをレンダリングできますが、2番目のウェーブで処理され、インデックス登録にはラグがあります。大規模なカタログの場合、そのラグはあなたにコストをもたらします。
---
スキップできない移行前監査
ぶっちゃけ、本番運用前にこれをやってない場合、あなたはすでに後れを取っています。ただし、遅すぎることはありません。
DNSレコードを1つ変更する前に、4つのものを用意しておきたい。
1. 既存のShopifyサイトの完全なクロール。Screaming Frogを使用してください（私はロンドンのローカルマシンで実行しています。クラウドクロールではなくローカルで、JavaScriptでレンダリングされるページを含めてすべてをキャッチできるようにしています）。すべてのURL、ステータスコード、タイトルタグ、メタディスクリプション、canonical、H1をエクスポートしてください。これがあなたのベースラインです。これがビフォー写真です。
2. マッピングドキュメント。古いURL → 新しいURLのすべて。カテゴリーページとプロダクトページだけじゃない。ブログ記事。タグページ。サイズガイドページ。2020年のプレスメンションから47本のバックリンクを持つ/pages/aboutというURL。クロール履歴、バックリンク、ランキングキーワードを持つすべてのURLが、このスプレッドシートに入る必要がある。
3. AhrefsもしくはSEMrushからのバックリンクエクスポート。少なくとも1つの参照ドメインを持つページでフィルタリング。これが最優先のリダイレクトターゲットだ。参照ドメイン12個を持つページで301リダイレクトを見落としたら、意味のあるリンクエクイティの塊を削除したも同然だ。
4. キーワードランキングのスナップショット。Google Search Consoleから現在のランキングをエクスポートしてください。最低でも、クリック数上位200クエリです。これは移行前後を比較するために必要です。「mens linen trousers」がライブ後に4位から22位に落ちたら、すぐに気づく必要があります。
---
ヘッドレスセットアップでのリダイレクト実装
ここはちょっと技術的になるが、ついてきてほしい。
標準的なShopifyセットアップでは、Shopify管理画面内でリダイレクトを管理します。Headlessセットアップでは、フロントエンドフレームワークがルーティングを処理しているため、デプロイメント先によってリダイレクトがどこに配置されるかが異なります。
Vercelを使用している場合（ほとんどのNext.js Headless Shopifyプロジェクトはここで終わります）、リダイレクトはvercel.jsonのreirectsアレイに入ります。301をきれいに処理し、Vercelのエッジネットワークがページのレンダリング前にそれらを適用します。これはSEOにとって正確に必要なものです。リダイレクトはインフラレイヤーで発生し、JavaScriptではありません。
Netlifyを使用している場合も同じ考え方で、netlify.tomlまたは_redirectsファイルです。
AWS CloudFront やカスタム Node サーバーのようなものでセルフホストしている場合は、リバースプロキシレベルでリダイレクトを実装する必要があります。React ルーターでやってはいけません。エッジレベルのリダイレクトはリンク価値をきちんと引き継ぎます。
私がいつもやることの1つは、すべてのリダイレクトを実装した後、httpstatus.io で一括チェックを実行してチェーンを検証することです。301 → 301 → 200 のチェーンは悪いです。301 → 200 にしたいです。リダイレクトチェーンはリンク価値を損失させ、処理を遅くします。
---
カノニカルタグ、構造化データ、そしてチームが忘れがちなこと
2023年、Seahawk は DTC スキンケアブランドをヘッドレス Hydrogen セットアップ（Shopify 独自の React フレームワーク）に移行させました。開発者はリダイレクト処理をしっかり行っていたのですが、Hydrogen はカノニカルタグを自動生成しないこと、つまり <head> 内で Hydrogen の SEO コンポーネントを使って手動で設定する必要があることを見落としていました。結果として、すべてのプロダクトページがクエリストリングパラメータを付けた状態で自分自身にカノニカライズされてしまいました。カート処理とフィルタロジックが URL にパラメータを書き込んでいたからです。Google は数百ページに及ぶ重複に近いプロダクトページを見ていました。
見つけたら修正に約1日かかりましたが、それが引き起こしたランキング変動が安定するまで約3週間かかりました。
ローンチ前に手動で確認すべきこと
- 商品ページのカノニカルタグはクリーンな URL（クエリストリングなし、UTM パラメータなし）を指しています。
- noindex はステージング環境と Vercel/Netlify のプレビュー URL に設定し、これはやることリストではなく、デプロイメントチェックリストに加えてください。
- 商品の構造化データ（Schema.org の Product タイプ）が <head> 内でサーバーレンダリングされており、ハイドレーション後にクライアント側スクリプトで注入されていません。
- robots.txt がルートドメインで到達可能で、Googlebot をあなたの新しい URL パターンからブロックしていません。
- XML サイトマップは新しい URL 構造を反映したものにしてください。古い Shopify サイトマップではなく、ビルドプロセスからのキャッシュ版でもありません。
---
Core Web Vitals：二律背反
ヘッドレスを売り込むとき、ほとんどのエージェンシーはこう言います。「Core Web Vitals が改善されます」と。そして、可能性としては間違っていません。画像最適化、エッジキャッシング、適切なコード分割を備えた、よく構築された Next.js フロントエンドなら、3 つすべての Core Web Vitals メトリクスで確実にグリーンに達することができます。
ですが、CWV を悪化させたヘッドレスマイグレーションも見てきました。具体的には LCP（Largest Contentful Paint）と CLS（Cumulative Layout Shift）です。
ヒーロー画像やファーストビュー内のプロダクト画像が適切にプリロードされていないと LCP は悪化します。ヘッドレスセットアップでは、画像パイプラインはあなたの責任です。もう Shopify の CDN に頼ることはできないので、フレームワークがヒーロー画像に priority フラグを使用していること（Next.js では、<Image> の priority プロップです）と、Cloudflare や Fastly のような CDN 経由で適切なサイズの画像を配信していることを確認する必要があります。
CLS が悪化するのは、フォントや動的コンテンツ（特にカートドロワーの状態、プロモーションバナー、フィルターチップ）がハイドレーション中にレイアウトシフトを引き起こす場合です。Shopify テーマはこれをそこそこ十分にハンドルします。あなたのカスタムヘッドレスフロントエンドはそうではありません。誰かが明確に設計しない限り。
ライブ前ではなく、ステージング URL で PageSpeed Insights を使ってテストしてください。サイトがステージングに十分長くいてデータを蓄積していれば、Chrome UX Report からフィールドデータを使用してください。そしてモバイルで確認してください。それが Google が実際にランキングに使うデータです。
---
クロールバジェットと大規模カタログ
プロダクト URL が 5,000 未満なら、クロール予算はおそらく主な懸念ではありません。しかし 50,000 以上の SKU、ファセットナビゲーション、複数の通貨・地域バリアント、そして 2015 年まで遡るブログを持つカタログを移行する場合は、このことを考慮する必要があります。
ヘッドレスセットアップは、それが置き換わるShopifyセットアップよりも多くのURLを生成することが多い。以前はShopifyではAJAXで処理されていたファセットフィルターでnoindexが付与されていたのに対し、URL パラメータハンドリングを慎重に考慮していないと、それぞれがサーバーレンダリング済みのルートを取得する。突然Googlebotが、以前は30,000個だったサイトの200,000URLをクロールしようとしている状態になってしまう。
robots.txt は厳密に保ってください。ユニークでランク可能なコンテンツを表さないフィルタ済み URL パターンのクローリングを disallow してください。フィルタ済みページで rel="canonical" を使ってルートカテゴリーに戻してください。そしてファセットの組み合わせごとにサーバーサイドルートを作成しないでください。そうすればクロール無駄と狂気への道へと向かいます。
---
移行がライブになり、クライアントが了承し、みんなが祝う。その後、1カ月間誰もSearch Consoleを見ない。そんなことをするな。
最初の3ヶ月間は最低でも週単位のGSCデータエクスポートをセットアップする。インプレッション、クリック、平均順位、インデックスカバレッジを追跡する。インデックスの低下を監視する。インデックス済みページ数が突然8,000から4,200に落ちた場合、何かが間違っており、Googleがそれらのページが永遠に消えたと判断する前に発見する必要がある。
最低でも最初の 3 ヶ月間は、毎週 GSC データをエクスポートするセットアップをしてください。インプレッション、クリック、平均掲載順位、インデックスカバレッジを追跡してください。インデックスの低下を監視し、インデックス済みページ数が突然 8,000 から 4,200 に落ちた場合は、Google がそれらのページが永遠に消えたと判断する前に、問題を見つける必要があります。
また、サイトマップ URL 自体（yourdomain.com/sitemap.xml）に対してアップタイムモニター（自分は Better Uptime を使用しています）をセットアップしました。デプロイ中に 500 を返すようになったら、3 日後にランキングが下がっているのに気づくのではなく、すぐに知りたいですね。
もう一つ。公開後は Search Console でサイトマップを再送信してください。当たり前かもしれませんが、これを忘れているのを見かけることは想像以上に多いです。
---
FAQ
ヘッドレス化は必ず最初は SEO に悪影響を与えますか？
必ずではありませんが、Google が新しい設定を再クロール・再インデックスする最初の4〜8週間は、ほぼ確実にランキングの変動が起こります。リダイレクトが堅牢で、カノニカルタグが正しく、構造化データが保持されていれば、通常は落ち着いて改善されることもあります。危険なのはマイグレーションが急いで実施された場合で、その場合は短期的な変動が長期的な損失に変わります。
Shopify の Hydrogen フレームワークを使いながら、SEO を良好に保つことはできますか？
はい。Hydrogen はデフォルトでサーバーサイドレンダリングを使用しており、これが SEO の正しい基盤です。不足しているのは詳細な部分、カノニカル管理、サイトマップ生成、構造化データです。Shopify は Hydrogen のコンポーネントライブラリに SEO ユーティリティを提供していますが、それは魔法ではありません。それが何をしているのか、なぜそうしているのかを理解している人が必要です。
移行の問題後、ランキングが回復するのにどのくらいの時間がかかりますか？
正直に言うと、深刻度によって異なります。少数のページでリダイレクトが欠けている場合は、修正すれば数週間で自動的に改善する可能性があります。サイト全体の canonical エラーや意図しないサイト全体への noindex は、回復に2～4か月かかることもあり、競争が激しい検索語の場合はそれ以上の期間がかかることもあります。早く発見して修正するほど、回復期間は短くなります。
ヘッドレス化は SEO の観点だけで見て価値がありますか？
いいえ。ヘッドレスは、パフォーマンス、柔軟性、フロントエンド開発者体験の点で価値があります。正しく移行すれば、SEO は中立的な要因です。エージェンシーが SEO のメリットを前面に出してヘッドレスを売り込まないようにしてください。同じパフォーマンスゲインは、多くの場合、最適化された Shopify 2.0 テーマと堅牢な CDN セットアップで、わずかなコストで達成できます。
---
マイグレーションはローンチではありません。Google が十分に知っている古い環境から、まだ知らない新しい環境への信頼の移譲です。すべての技術的詳細が重要であるかのように扱ってください。なぜなら、オーガニック チャネルにとって、実際に重要だからです。