NuvemshopからShopifyへ：SEOを失わずに移行する方法
NuvemshopからShopifyへSEOを落とさずに移行する手順。旧URLの洗い出し、パスごとの対応づけ、CSVによる301の一括登録、Google Merchant Centerフィードの修正まで解説します。
要点
NuvemshopからShopifyへの移行は、URLマップの入れ替えです。SEOが失われるか持ちこたえるかは、ここで決まります。オーガニック検索で売上を立てていて、移行先をすでに決めたストアが対象です。評価はプラットフォームに宿るのではなく、インデックスされたアドレスと、そこを指すリンクに宿ります。Shopifyは商品を /products/{handle}、コレクションを /collections/{handle}、記事を /blogs/{blog}/{article} で配信し（articleオブジェクト）、この形式は書き換えられません。ですから計算は単純です。今クリックを生んでいるすべてのURLに、新しい対応先への301が必要です。Googleは301を恒久的なものとして扱い、転送先を表示するようになります（Google Search Central）。誰も対応づけないのは、それ以外の部分です。入れ子のカテゴリ、タグ、ブログ、画像、そしてMerchant Centerのフィード。プラットフォームの選択がまだ決まっていないなら、公開中の記事は Tray vs Shopify と WooCommerceのリスク です。
1. SEOはプラットフォームではなくURLマップにある
ドメインが同じままでパスだけが変わる場合、Googleはサイト全体を学び直す必要はありません。必要なのは、古いアドレスそれぞれで新しいアドレスへの301を見つけることです。それがなければ旧URLは404を返し（テンプレートのアーキテクチャによると、Shopifyは無効なパスに 404 テンプレートを返します）、そのアドレスに蓄積されたシグナルは流れなくなります。
2つのプラットフォームの違いは見た目ではなく構造にあります。Nuvemshopでは、商品とカテゴリが名前から生成された handle を言語ごとに持ち、カテゴリには実際の階層があります。parent フィールドと subcategories リストが存在します（Product、Category）。Shopifyでは、コレクションはフラットです。Liquidの collection オブジェクトは handle、title、products、tags を公開しますが、親コレクションもサブコレクションも公開しません（collectionオブジェクト）。
つまり、2〜3階層のカテゴリツリーは、同じ階層に並ぶコレクションの集合になります。これはテーマの細部ではなく、マッピングの判断です。先に決めなかった人は、あとでサブカテゴリのURLに404が連続して出ることで気づきます。しかもそれは、コンバージョンにつながるロングテールのページであることが多いのです。
2. 何かに手をつける前に、実際のURLリストを洗い出す
カタログをエクスポートして終わった気になりがちです。カタログは在庫の一覧にすぎません。Googleがインデックスしたものは別のリストで、存在すら忘れていたページも含まれます。3つの情報源を、この順番で合わせます。
現在のストアのサイトマップからは、プラットフォームが今公開しているものがわかります。Search Consoleからは、実際にクリックと表示回数を得ているものがわかります（検索パフォーマンスのレポート、ページ別のエクスポート、レポートで選べる最長の期間）。サーバーや事業者のログからは、今もクロールされているものがわかります。サイトマップから消えたのに、まだアクセスされている古いURLも含まれます。
3つ目が、きちんとやった移行と祈るだけの移行を分けるポイントです。Googleは、サイト移転の棚卸しをする際に最近アクセスされたURLを確認するよう勧めています（How to move a site）。廃止したカテゴリページ、被リンクのある販売終了商品、古いブログ記事。カタログにもう存在しなくても、すべてスプレッドシートに入れます。
手間のかからない確認方法として、サイトマップをダウンロードし、パスの種類ごとにURLを数えます。
curl -s https://sualoja.com.br/sitemap.xml \
| grep -o '<loc>[^<]*</loc>' | wc -l
3. マッピング用スプレッドシート、列ごとの説明
マップは移行元と移行先を並べたスプレッドシートで、それ以上のものではありません。Shopifyは UrlRedirect オブジェクトでこの2つのフィールドを path と target と呼びます（Admin GraphQL）。path は旧パス、target はユーザーが移動する先です。作業用に列を3つ追加しておくと便利です。種類（商品、カテゴリ、ブログ、ページ、タグ）、エクスポート期間のクリック数、確認ステータスです。
アルファベット順ではなく、クリック数で並べ替えます。時間を節約するルールはこうです。トラフィックのある商品とカテゴリは転送先を1件ずつ確認し、それ以外はルールで埋めてサンプルで確認します。両側でhandleが同じでも、プレフィックスが変わるのでURLは同じになりません。handleが違えば（アクセント記号の除去方法が違う、インポート時に商品名を編集した、など）、正しい商品を取り込んでいても301は壊れます。
よくある失敗は2つです。1つ目はチェーンです。旧URLが中間URLを指し、それがさらに最終URLを指す状態です。Googleはサイト移転でリダイレクトチェーンを避けるよう求めています。2つ目は手抜きの近道で、転送先が見つからないものをすべてトップページに送ることです。トップページへの一括リダイレクトは、検索意図に応えないページを訪問者に見せることになります。販売終了の商品は対応するコレクションに向けるほうがよく、対応先がまったくないものだけを正直に404にします。
4. パスの対応表、種類ごと
Shopifyのルートの形式は、Liquidの routes オブジェクトに記載されています。/collections、/collections/all、/search、/cart です（routes）。下の表は、これをNuvemshopがAPIで公開している構造と突き合わせた結果です。確認日は2026年9月18日です。
| ページの種類 | Nuvemshop | Shopify | 301での注意点 |
|---|---|---|---|
| 商品 | 商品の handle を含むパス、言語ごとに1つ（Product） |
/products/{handle} |
インポート時にhandleが書き換わると、正しい商品でもマップが壊れる |
| カテゴリ | 言語ごとの handle、parent と subcategories あり（Category） |
/collections/{handle}、階層なし（collection） |
サブカテゴリはフラットなコレクションになる。転送先を先に決める |
| カテゴリ一覧 | 最大1,000カテゴリのツリー（Category） | /collections と /collections/all（routes） |
特定のカテゴリを /collections/all に送らない |
| ブログ | 記事独自のパス | /blogs/{blog}/{article}（article） |
ブログ名がパスに入ることを忘れがち |
| 検索 | 独自のパス | /search（routes） |
インデックスされた検索ページは301ではなく noindex の候補 |
| プラットフォームのドメイン | nuvemshop.com.br 上の original_domain（Store） |
*.myshopify.com |
プラットフォームのドメインがインデックスされていたら、それは別の移行 |
大規模ストアではカタログの上限も考慮に入ります。NuvemshopのAPIは、422とともに「Store has reached maximum limit of 100000 allowed products」「Store has reached maximum limit of 1000 allowed categories」を返します（Product、Category）。移行ではなくプラットフォームの上限ですが、スプレッドシートの規模感の目安になります。
切り替えの前後にサンプルで確認しておけば、数週間後にSearch Consoleで問題に気づく事態を避けられます。
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
https://sualoja.com.br/produto-antigo
5. 301を1件ずつ入力せず、一括で登録する
数百のURLを持つストアで、手入力は現実的ではありません。ShopifyはCSVでリダイレクトを一括インポートでき、公式に記載された方法は urlRedirectImportCreate ミューテーションです。これは「The staged upload URL of the CSV file」を受け取り、write_online_store_navigation スコープが必要です。その後、urlRedirectImportSubmit で送信します（Admin GraphQL）。同じページにサンプルCSVがあるので、自分のCSVを作る前に形式を確認できます。
CSVは、セクション3のスプレッドシートを旧パスと転送先の2列に絞ったものです。APIを使わなくても、同じファイルを管理画面のリダイレクトのインポートから登録できます。大事なのは中身であって、入口ではありません。
インポート前に確認すること
最初から最後まで一貫した相対パスにし、絶対URLとパスを混在させないこと。同じファイル内の別の行を指す行を作らないこと（それはGoogleが避けるよう求めるチェーンです）。転送先が新しいストアに実在することを、スプレッドシートを眺めるのではなくHTTPレスポンスで確認すること。Nuvemshopの handle はすでに正規化されていますが、あなたのスプレッドシートはそうとは限らないため、アクセント記号と大文字小文字をリスト全体で同じように扱うこと。
インポート後、既存のリダイレクトの読み取りには urlRedirects クエリを read_online_store_navigation スコープで使います（UrlRedirect）。登録された内容を元のスプレッドシートと比較する監査に役立ちます。
6. 商品以外で壊れるもの：コレクション、タグ、ブログ、画像
商品は簡単な部分です。SKUと商品名があるので、確認の足がかりになります。トラフィックを落とすのはそれ以外のものです。
入れ子のコレクション。 Nuvemshopの階層に相当するものはShopifyにありません。独自のトラフィックを持つサブカテゴリは、独自のhandleと独自の301を持つ独立したコレクションにする必要があります。すべてを親カテゴリに押し込むと、異なる検索意図がひとつのページにまとめられてしまいます。
タグ。 Shopifyはタグをフィルターとコレクションの自動化に使います。collection オブジェクトが all_tags で返すタグは最大1,000件で、商品が5,000件を超えるコレクションではストアフロントのフィルターが空になります（collection）。以前の戦略がインデックスされたタグページに頼っていたなら、テーマで場当たり的に対処するのではなく、マップで明示的な転送先を決める必要があります。
ブログ。 古いリンクが最も失われやすい場所です。ShopifyのURLはパスの途中にブログ名を含むためです（article）。旧パスを対応づけずに記事を移行すると、すでに順位がつき、作るのに時間がかかったコンテンツを捨てることになります。
画像。 画像はShopifyのCDNから別のアドレスで配信されるようになります。Google画像検索にインデックスされていたものは自然に再インデックスされます。本当の問題は、以前のホストを指している古いコンテンツです。robots.txt も見直しておきましょう。Shopifyでは robots.txt.liquid テンプレートで、Liquidで書く必要があります（Templates）。
内部リンク。 切り替え後、サイト内のすべてのリンクは301を経由せず、新しいURLを直接指すようにします。リダイレクトは外部リンクとGoogleのインデックスのためのもので、テーマの手間を省くためのものではありません。
7. Merchant Center、広告、合わなくなるフィード
Merchant Centerはストアの管理画面を見ていません。見ているのはURLです。パスが変われば、各商品のリンク先が変わります。Googleの仕様では、フィードとサイトのデータの不一致を不承認の一般的な原因として扱い、ランディングページ独自の要件を挙げています（商品データ仕様）。
注意すべきは id 属性です。同じ仕様で、商品の一意の識別子と定義されています。全商品の id を一度に変えると、各商品の履歴をリセットすることになります。id は安定させたまま、リンクと在庫状況だけを変えるのが最も波風の立たない方法です。
最終URLが固定された有料広告や、SNS、メール、マーケットプレイスのリンクも同じです。301は旧パスから来た人をカバーしますが、実施中のキャンペーンのリンクは元で直すほうが確実です。切り替え前にやるべき当然の確認として、転送先のリストを一通り叩き、すべて200が返ることを確かめます。
8. 切り替え後：何を測り、どれだけ維持するか
リダイレクトは1日で終わる作業ではなく、残り続けるインフラです。Googleははっきりと、リダイレクトはできるだけ長く、「generally at least 1 year」維持するよう述べています（How to move a site）。「もう済んだから」と2か月後にリストを消すのは、作業を捨てることです。
最初の数週間は、3つの画面でほぼすべてがわかります。Search Consoleのカバレッジとページのレポートでは、404がまとまって出てくる様子が見えます。これはマップから漏れたURLの症状です。検索パフォーマンスのレポートをページ別に比較すると、どのパスがクリックを失ったかがわかり、足りない301を見つけられます。Merchant Centerではランディングページによる不承認が見え、たいていここが最初に警告を出します。
Search Consoleのアドレス変更ツールについて。これはドメインを変えるためのもので、パスを変えるためのものではありません。ヘルプ自体が、サイト内で一部のページをある場所から別の場所へ移すだけなら使わないよう書いており、その場合はリダイレクトを追加してサイトマップを更新すれば十分です。ドメインレベルのプロパティが必要で、移転元と移転先の両方の所有者である必要があり、シグナルを180日間転送します（Search Console ヘルプ）。両側でドメインが同じなら、301のマップだけで役目を果たします。
再インデックスは切り替え当日には起きません。Googleは自分のペースでクロールし、古いリストは各URLが再訪問されるにつれて少しずつインデックスから外れます。最初の数週間の変動は普通です。クリックのあるページの404は普通ではありません。カタログ、切り替え、DNSの実務的な手順については、関連記事のストアを止めない移行チェックリストをご覧ください。
よくある質問
NuvemshopからShopifyへ移行すると、Googleの順位は下がりますか？
ここに保証や誠実な数値予測はありません。パーセンテージを示す人は作り話をしています。コントロールできるのは、順位低下の最も多い原因、つまり301のない旧URLです。チェーンがなく、対応する転送先を持つ完全なマップこそ、Googleがサイト移転のドキュメントで求めているものです。対応づけなかったものは404になり、クリックのあるページの404は確実な損失です。
旧URLをShopifyでもそのまま維持できますか？
プレフィックスは維持できません。Shopify自身のテーマとLiquidのドキュメントのとおり、商品は /products/、コレクションは /collections/、記事は /blogs/{blog}/ の下に置かれます。handle は自分で決められますが、プレフィックスは決められません。だから移行は常にパスの変更であり、同じドメインを使い続けても常に301が必要です。
リダイレクトはどれくらいの期間有効にしておく必要がありますか？
少なくとも1年です。これはURL変更を伴うサイト移転に対するGoogleの推奨です。実際には、ShopifyのURLリダイレクトは保守の手間も体感できるパフォーマンスへの影響もないので、消す理由はありません。古い被リンクは1年を過ぎてもずっと届き続けます。
移行のついでにカテゴリを整理し直したい場合は？
技術的には可能ですが、同じ切り替えで行うのはリスクを重ねることです。Googleは、サイト移転とコンテンツやURL構造の刷新を同時に行うと、ページを改めて検出・評価する必要があるため、トラフィックを失う可能性が高いと警告しています。できるだけ近い構造で移行し、安定させ、そのあとで整理し直してください。やむを得ない例外は、Shopifyが再現できないカテゴリの階層です。
Merchant Centerのフィードを一から作り直す必要がありますか？
フィードはShopifyから出力されるようになるので、情報源は変わります。避けたいのは、必要もないのに全商品の id 属性を変えることです。Googleの仕様では、それが商品の一意の識別子だからです。できる限り id は変えず、リンクと在庫状況を実際に変わったフィールドとして扱ってください。
まとめ
NuvemshopからShopifyへの移行は、テーマ選びではなくURLのスプレッドシートで決まります。3つの情報源から実際の棚卸しをし、パスの種類ごとに対応づけ、CSVで301を登録し、そのあとで残りの課題に目を向けます。入れ子のコレクション、タグ、ブログ、画像、フィードです。切り替え後の仕事は、404を監視し、リダイレクトを少なくとも1年間維持することです。あなたのストアがこの計算に当てはまるか知りたい場合は、現在のプラットフォーム、プラン、URLを oailton.dev/ja/contato からお送りください。まだShopifyストアを作っていないなら、作る前にご相談ください。ストアは開発ストアとして立ち上げ、完成した状態で構築してから、あなたの名義に移管します。