2022年初頭、あるクライアントが私のもとに来ました――中規模ファッションブランド、月間自然検索セッション数は約40,000、ドメインレーティングは悪くない、Shopifyを4年間使用していました。彼らはdev agencyを雇い、Next.jsとShopifyのStorefront APIを使ってサイト全体を再構築していました。新しいサイトは素晴らしかったです。本当に速かったです。ところが、リリースから6週間以内に、自然検索トラフィックの38%を失ってしまったのです。
重要なポイント：Headless Shopifyへの移行は、すべての移行と同じ方法でランキングを保護します。つまり、完全なリダイレクトマップ、バイト単位で同一のメタデータ転送、および新しいビルドに対するCore Web Vitalsの予算配分です。Headless Shopify migrations protect rankings the same way every migration does: full redirect map, byte-identical metadata transport, and a Core Web Vitals budget on the new build.
リダイレクト監査を実施していなかった。サイトマップが壊れていた。カノニカルタグが間違った環境を指していた。これは大災害で、事態が安定するまで約 6 万ポンドの売上を失った。
Headless移行は、純粋な技術的勝利に見えるもの――レンダリングが高速、フロントエンドの分離、完全な設計の自由――ですが、SEOを後付けとして扱えば、ひどい代償を払うことになります。Seahawkで12,000以上のサイトに携わってきた私は、このパターンが十分に繰り返されるのを見てきたので、これをきちんと書き残しておきたいと思いました。look like a pure technical win -- faster rendering, decoupled front-end, total design freedom -- but if you treat SEO as an afterthought, you'll pay for it. Badly. I've worked on 12,000+ sites at Seahawk and I've seen this pattern repeat itself enough times that I wanted to write it all down properly.
---
ヘッドレス Shopify が最初の場所で SEO を壊す理由
Shopifyの標準テーマアーキテクチャは、あなたが気づかないうちにSEOの重い処理の多くを肩代わりしています。Canonicalタグは自動生成されます。/sitemap.xmlにあるsitemap.xmlは自動的に保守されます。商品の構造化データはLiquidを通じてあらかじめ組み込まれています。ページネーションはShopifyが静かにバックグラウンドで管理するrel="next"およびrel="prev"の慣例を使用しています。/sitemap.xml is maintained automatically. Structured data for products comes baked in via Liquid. Pagination uses rel="next" and rel="prev" conventions that Shopify manages quietly in the background.
Headlessに移行した瞬間――通常、Next.js、Nuxt、Remix、SvelteKitのようなフレームワークがShopify Storefront APIからデータを取得します――すべての管理があなたの手に渡ります。すべてのcanonical。すべてのhreflang。すべての構造化データブロック。すべてのリダイレクト。もう無料では手に入りません。Next.js, Nuxt, Remix, or SvelteKit pulling data from the Shopify Storefront API -- you own all of that. Every canonical. Every hreflang. Every structured data block. Every redirect. It doesn't come for free anymore.
そして、ここが肝心な点です。ほとんどのdev チームはReactが得意だから雇われます。ファセット化されたナビゲーションクロールトラップがどのように見えるかを知っているからではなく。
私が常に見かける3つの失敗パターン
- ステージング環境のURLが本番インデックスに漏れる。dev チームがstaging.mybrand.comまたはVercelプレビューURL上で構築し、適切にnoindexを指定し忘れて、Googleがクロールし、突然ライブサイトと競合する重複コンテンツが発生します。 The dev team builds on
staging.mybrand.comor a Vercel preview URL, forgets tonoindexit properly, Google crawls it, and suddenly you have duplicate content competing with your live site. - URL再構築時の破損または欠落したリダイレクト。ヘッドレスプロジェクトはほぼ常にURLの変更を伴います。/collections/mens-shirtsが/category/shirtsまたはそれ以上に悪いものになります。301が配置されていないと、すべてのインバウンドリンクとGoogleインデックス登録済みのURLが404を返します。 Headless projects almost always involve URL changes.
/collections/mens-shirtsbecomes/category/shirtsor something worse. Without 301s in place, every inbound link and every Google-indexed URL returns a 404. - クライアント側レンダリングが低い。ヘッドレスフロントエンドがSSRやSSGなしで純粋にクライアント側で商品コンテンツをレンダリングしている場合、GooglebotがコンテンツをY確実に取得していない可能性があります。GoogleはJavaScriptをレンダリングできますが、2番目のウェーブで処理され、インデックス登録にはラグがあります。大規模なカタログの場合、そのラグはあなたにコストをもたらします。 If your headless front-end is rendering product content purely client-side without SSR or SSG, Googlebot may not be picking up your content reliably. Google can render JavaScript, but it's processed in a second wave and there's indexing lag. For large catalogues, that lag costs you.
---
スキップできない移行前監査
ぶっちゃけ、本番運用前にこれをやってない場合、あなたはすでに後れを取っています。ただし、遅すぎることはありません。
DNSレコードを1つ変更する前に、4つのものを用意しておきたい。
1. 既存のShopifyサイトの完全クロール。Screaming Frogを使用してください（ロンドンの専用マシンでローカルに実行しています――クラウドクロールではなくローカルなので、JavaScriptで描画されたページを含むすべてをキャッチできます）。すべてのURL、ステータスコード、タイトルタグ、メタディスクリプション、canonical、H1をエクスポートしてください。これがあなたのベースラインです。これがあなたの「移行前」の写真です。 Use Screaming Frog (I run it locally here in London on a dedicated machine -- not cloud crawl, local, so I can catch everything including JavaScript-rendered pages). Export every URL, status code, title tag, meta description, canonical, and H1. This is your baseline. It's your before-photo.
2. マッピングドキュメント。古いURL → 新しいURLのすべて。カテゴリーページとプロダクトページだけじゃない。ブログ記事。タグページ。サイズガイドページ。2020年のプレスメンションから47本のバックリンクを持つ/pages/aboutというURL。クロール履歴、バックリンク、ランキングキーワードを持つすべてのURLが、このスプレッドシートに入る必要がある。 Every old URL → new URL. Not just category and product pages. Blog posts. Tag pages. Size guide pages. The /pages/about URL that has 47 backlinks from that press mention in 2020. Every URL that has crawl history, backlinks, or ranking keywords needs to be in this spreadsheet.
3. AhrefsもしくはSEMrushからのバックリンクエクスポート。少なくとも1つの参照ドメインを持つページでフィルタリング。これが最優先のリダイレクトターゲットだ。参照ドメイン12個を持つページで301リダイレクトを見落としたら、意味のあるリンクエクイティの塊を削除したも同然だ。 Filter to pages with at least one referring domain. These are your highest-priority redirect targets. Miss a 301 on a page with 12 referring domains and you've just deleted a meaningful chunk of link equity.
4. キーワード順位スナップショット。Google Search Consoleから現在の順位をエクスポートしてください――最低限、クリック数が多い上位200クエリです。移行の前後を比較できるようにこれが必要です。「mens linen trousers」がリリース後に4位から22位に下がった場合、すぐにそれに気付く必要があります。 Export your current rankings from Google Search Console -- at minimum, the top 200 queries by click volume. You need this so you can compare pre- and post-migration. If "mens linen trousers" drops from position 4 to position 22 after go-live, you need to be able to spot that immediately.
---
ヘッドレスセットアップでのリダイレクト実装
ここはちょっと技術的になるが、ついてきてほしい。
標準的なShopifyの設定では、Shopify管理画面内でリダイレクトを管理します。Headlessの設定では、フロントエンドフレームワークがルーティングを処理しています――つまり、デプロイターゲットによってリダイレクトはどこか別の場所に存在することになります。
Vercel上にいる場合（ほとんどのNext.js headless Shopifyプロジェクトが終わる場所です）、リダイレクトはvercel.jsonのredirectsアレイに入ります。301をきれいに処理し、Vercelのエッジネットワークがページを描画する前にリダイレクトを適用します。これはSEOにとって正確に望みのもの――リダイレクトはインフラストラクチャレイアーで発生し、JavaScriptではありません。vercel.json under the redirects array. It handles 301s cleanly and Vercel's edge network applies them before the page even renders, which is exactly what you want for SEO -- the redirect happens at the infrastructure layer, not in JavaScript.
Netlifyにいる場合も同じ考え――netlify.tomlか_redirectsファイルです。Netlify, same idea -- netlify.toml or a _redirects file.
AWS CloudFront やカスタム Node サーバーのようなものでセルフホストしている場合は、リバースプロキシレベルでリダイレクトを実装する必要があります。React ルーターでやってはいけません。エッジレベルのリダイレクトはリンク価値をきちんと引き継ぎます。
私がいつもやることの1つは、すべてのリダイレクトを実装した後、httpstatus.io で一括チェックを実行してチェーンを検証することです。301 → 301 → 200 のチェーンは悪いです。301 → 200 にしたいです。リダイレクトチェーンはリンク価値を損失させ、処理を遅くします。httpstatus.io to verify the chain. A 301 → 301 → 200 chain is bad. You want 301 → 200. Redirect chains bleed link equity and slow things down.
---
カノニカルタグ、構造化データ、そしてチームが忘れがちなこと
2023年、Seahawkは、あるDTC（ダイレクト・トゥ・コンシューマー）スキンケアブランドをヘッドレスのHydrogen設定（Shopify独自のReactフレームワーク）に移行させました。開発チームはリダイレクト処理をきちんと実装していました。しかし、Hydrogenは正規タグ（canonical tag）を自動生成しないことを見落としていたのです。<head>内でHydrogenのSEOコンポーネントを使って手動で設定する必要があります。その結果、カートとフィルター処理がURLにパラメータを書き込んでいたため、すべての商品ページがクエリ文字列パラメータを付けた自身のページに正規化されていました。Googleは数百ページのほぼ重複した商品ページを見ていたことになります。<head> using Hydrogen's SEO component. Result: every product page was canonicalising to itself with the query string parameters appended, because the cart and filter logic was writing params into the URL. Google was seeing hundreds of near-duplicate product pages.
見つけたら修正に約1日かかりましたが、それが引き起こしたランキング変動が安定するまで約3週間かかりました。
ローンチ前に手動で確認すべきこと
- 商品ページのカノニカルタグはクリーンな URL（クエリストリングなし、UTM パラメータなし）を指しています。
noindexはステージング環境とVercel/NetlifyのプレビューURLに設定してください。これはやることリストではなく、デプロイメントのチェックリストに追加する項目です。is on your staging environment and any Vercel/Netlify preview URLs -- add this to your deployment checklist, not your to-do list.- 商品の構造化データ（Schema.org の Product タイプ）が <head> 内でサーバーレンダリングされており、ハイドレーション後にクライアント側スクリプトで注入されていません。Schema.org
Producttype) is being server-rendered in the<head>, not injected by a client-side script after hydration. - robots.txt がルートドメインで到達可能で、Googlebot をあなたの新しい URL パターンからブロックしていません。
robots.txtis reachable at the root domain and isn't blocking Googlebot from your new URL patterns. - XMLサイトマップは新しいURL構造を反映している必要があります。古いShopifyのサイトマップではなく、ビルドプロセスからのキャッシュ版でもなく。
---
Core Web Vitals：二律背反
ヘッドレスを売り込むときにほとんどのエージェンシーが使う売り文句がこれです。「Core Web Vitalsが改善されます」。彼らが間違っていないわけではありません。可能性としてはそうです。画像最適化、エッジキャッシング、適切なコード分割を備えた、よく構築されたNext.jsフロントエンドなら、Core Web Vitals の3つのメトリクス全体で実際に緑を達成できます。potentially. A well-built Next.js front-end with image optimisation, edge caching, and proper code splitting can genuinely hit green across all three Core Web Vitals metrics.
ですが、CWV を悪化させたヘッドレスマイグレーションも見てきました。具体的には LCP（Largest Contentful Paint）と CLS（Cumulative Layout Shift）です。worse. Specifically LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift).
ヒーロー画像やファーストビューの商品画像が正しくプリロードされていないと、LCPは悪化します。ヘッドレス設定では、画像パイプラインはあなたの責任です。もはやShopifyのCDNに頼ることはできません。フレームワークがヒーロー画像に優先度フラグを使用していることを確認する必要があります（Next.jsではそれは<Image>のpriortyプロップです）。また、CloudflareやFastlyのようなCDNを通じて適切なサイズの画像を配信していることを確認してください。priority flags on hero images (in Next.js, that's the priority prop on <Image>) and that you're serving correctly sized images via a CDN like Cloudflare or Fastly.
CLS が悪化するのは、フォントや動的コンテンツ（特にカートドロワーの状態、プロモーションバナー、フィルターチップ）がハイドレーション中にレイアウトシフトを引き起こす場合です。Shopify テーマはこれをそこそこ十分にハンドルします。あなたのカスタムヘッドレスフロントエンドはそうではありません。誰かが明確に設計しない限り。
ゴーライブ後ではなく、ステージングURLでPageSpeed Insightsを使ってテストしてください。Chrome UX Reportからのフィールドデータを使用してください。ステージングが十分に長く実行されていてデータが蓄積されている場合。そしてモバイルでチェックしてください。それがGoogleが実際にランキングに使用するデータです。PageSpeed Insights on your staging URL before go-live, not after. Use field data from Chrome UX Report if the site has been in staging long enough to accumulate it. And check on mobile -- that's the data Google actually uses for ranking.
---
クロールバジェットと大規模カタログ
商品URLが5,000未満なら、クローラー予算はおそらく主な関心事ではありません。しかし、50,000以上のSKU、ファセットナビゲーション、複数の通貨/地域バリアント、そして2015年までさかのぼるブログを持つカタログを移行する場合は、これについて考える必要があります。
ヘッドレスセットアップは、それが置き換わるShopifyセットアップよりも多くのURLを生成することが多い。以前はShopifyではAJAXで処理されていたファセットフィルターでnoindexが付与されていたのに対し、URL パラメータハンドリングを慎重に考慮していないと、それぞれがサーバーレンダリング済みのルートを取得する。突然Googlebotが、以前は30,000個だったサイトの200,000URLをクロールしようとしている状態になってしまう。more URLs than the Shopify setup they're replacing. Faceted filters that were previously handled via AJAX with noindex in Shopify now get their own server-rendered routes if someone hasn't thought carefully about URL parameter handling. Suddenly Googlebot is trying to crawl a 200,000-URL site when you had 30,000 before.
robots.txtはシンプルに保ちましょう。一意でランク付け可能なコンテンツを表さないフィルター済みURLパターンのクローリングを禁止します。フィルター済みページにrel="canonical"を使用して、ルートカテゴリにポイントさせてください。すべてのファセット組み合わせのために個別のサーバーサイドルートを作成しないでください。そうするとクローラー予算の浪費と狂気の道へ向かいます。robots.txt tight. Disallow crawling of filtered URL patterns that don't represent unique, rankable content. Use rel="canonical" on filtered pages to point back to the root category. And don't create individual server-side routes for every facet combination -- that way lies madness and crawl waste.
---
移行がライブになり、クライアントが了承し、みんなが祝う。その後、1カ月間誰もSearch Consoleを見ない。そんなことをするな。
最初の3ヶ月間は最低でも週単位のGSCデータエクスポートをセットアップする。インプレッション、クリック、平均順位、インデックスカバレッジを追跡する。インデックスの低下を監視する。インデックス済みページ数が突然8,000から4,200に落ちた場合、何かが間違っており、Googleがそれらのページが永遠に消えたと判断する前に発見する必要がある。
最初の3ヶ月間は最低でも週1回、GSCデータのエクスポートをセットアップしてください。インプレッション、クリック、平均順位、インデックスカバレッジを追跡します。インデックス低下を監視してください。インデックス済みページ数が8,000から4,200に急に落ちた場合、何か問題があり、Googleがそれらのページが永遠に削除されたと判断する前に見つける必要があります。
また、サイトマップURL自体（yourdomain.com/sitemap.xml）に稼働時間モニター（私はBetter Uptimeを使用しています）をセットアップしました。デプロイ中に500を返し始めたら、3日後にランキングが低下していることに気付く前に、すぐに知りたいものです。yourdomain.com/sitemap.xml. If it starts returning a 500 during a deployment, you want to know immediately, not three days later when you notice rankings sliding.
もう一つ。公開後は Search Console でサイトマップを再送信してください。当たり前かもしれませんが、これを忘れているのを見かけることは想像以上に多いです。
---
FAQ
ヘッドレス化は必ず最初は SEO に悪影響を与えますか？
必ずではありませんが、Google が新しい設定を再クロールし、再インデックスする際、最初の4～8週間でランキング変動がほぼ確実に発生します。リダイレクトが堅牢で、正規化タグが正しく、構造化データが完全な状態であれば、通常は落ち着きを取り戻し、しばしば改善されます。危険なのはマイグレーションが急いで実行される場合です。その場合、短期的な変動が長期的な損失に変わります。
Shopify の Hydrogen フレームワークを使いながら、SEO を良好に保つことはできますか？
はい。Hydrogen はデフォルトでサーバーサイドレンダリングを使用しており、これは SEO の正しい基礎です。ギャップは詳細にあります。正規化管理、サイトマップ生成、構造化データです。Shopify は Hydrogen のコンポーネントライブラリで SEO ユーティリティを提供していますが、魔法ではありません。それが何をしているのか、なぜそうしているのかを理解している人が必要です。
移行の問題後、ランキングが回復するのにどのくらいの時間がかかりますか？
正直に言うと、深刻度によって異なります。少数のページでリダイレクトが欠けている場合は、修正すれば数週間で自動的に改善する可能性があります。サイト全体の canonical エラーや意図しないサイト全体への noindex は、回復に2～4か月かかることもあり、競争が激しい検索語の場合はそれ以上の期間がかかることもあります。早く発見して修正するほど、回復期間は短くなります。noindex on your entire domain can take two to four months to recover from, sometimes longer for highly competitive terms. The sooner you catch and fix it, the shorter the recovery.
ヘッドレス化は SEO の観点だけで見て価値がありますか？
いいえ。Headless はパフォーマンス、柔軟性、フロントエンド開発者体験のために価値があります。正しく移行すれば、SEO は中立的な要素です。エージェンシーが SEO の利点を前面に押し出して Headless を売りつけるように誘導されないでください。同じパフォーマンス向上は、多くの場合、よく最適化された Shopify 2.0 テーマと堅牢な CDN セットアップでは、わずかな費用で達成できます。if you migrate correctly. Don't let an agency sell you headless by leading with SEO benefits -- the same performance gains can often be achieved with a well-optimised Shopify 2.0 theme and a solid CDN setup, at a fraction of the cost.
---
マイグレーションはローンチではありません。信頼の移行です。Google が十分に知っている古い環境から、まだ知らない新しい環境への移行です。すべての技術的詳細が重要であるかのように扱ってください。オーガニックチャネルにとっては、実際に重要だからです。