TrayからShopifyへの移行：注文とSEOで気をつけること

要点

TrayからShopifyへ移行するとは、既存ストアの運用を別のプラットフォームへ移し、データを残し、顧客と検索エンジンがすでに知っているアドレスを扱うことです。作業はテーマ選びからではなく、カタログ、顧客、注文履歴のエクスポートから始まります。そのあと、確認済みのインポート、リダイレクトのマップ、在庫・配送・決済の検証が続き、最後にDNSを切り替えます。ストア運営者はアクセス、商売上の判断、連絡を担います。開発者はデータの変換、実装、技術的な確認を担います。この手順はリスクを下げますが、損失がゼロであること、Googleの順位が安定すること、中断がまったくないことを約束するものではありません。

1. 何が変わり、各成果物を誰が承認するかを決める

TrayからShopifyへ移す前に、変更の理由を運用の言葉で書いてください。テーマを育てにくいこと、別の連携が必要なこと、購買体験を組み直すこと、などが理由になり得ます。切り替えが意味を持つのは、提案する解決がその理由に応え、対応、在庫、請求でより大きな問題を生まないときだけです。

プラットフォームの判断がまだ開いているなら、比較記事のTrayとShopify：テーマ、コスト、連携から始めてください。ここでは、判断を責任の明確な、制御された移行に変えることが焦点です。ECの構築と移行のプロジェクトには、データ、運用、旧アドレスを含めます。似たストアフロントを渡すだけでは足りません。

ストア運営者は文脈を渡し、商売上の行き先を決めます。 現在のプランを伝え、必要なアクセスを開き、ドメインを誰が管理しているかを示し、ERP、決済手段、配送サービスを挙げます。どの商品を残し、どれを外し、変更前の購入を誰が対応するかも決めます。アクセスは各サービスの適切な仕組みで渡し、スプレッドシートでパスワードを送らないでください。

開発者は、その判断を受け入れ基準に変えます。 何をインポートするか、何を照会用ファイルに残すか、どの連携を作り直すか、古い注文をチームがどう見つけるかを文書にします。テーマはこの範囲に入りますが、これらの成果物の代わりにはなりません。見た目のよいページは、バリエーションの登録や配送ルールが正しいことを示しません。

切り替えの時間帯と、それを遅らせる条件を決めてください。決済の失敗、在庫の食い違い、重要なページの誤った行き先は、ドメインを向ける前に直す理由です。ストア運営者が商売上の準備を承認し、開発者が技術的な証拠を出します。どちらも、切り替えの瞬間に自分の責任を知ることになるべきではありません。

2. Trayのデータをエクスポートし、元ファイルを残す

2026年10月19日に確認したTrayのヘルプセンターは、カタログを Produtos > Lista de Produtos > Mais opções > Exportar produtos（商品 > 商品一覧 > その他のオプション > 商品をエクスポート）から書き出すよう案内しています。この依頼では、バリエーション、商品のステータス、在庫を選べます。処理が終わると、ファイルをダウンロードする通知が出ます。有効な商品だけのエクスポートを、選んだ内容を確認せずにカタログの完全なコピーとして扱わないでください。

この移行元には重要な点があります。ドキュメントは、一部のテキスト項目が調整され、アクセント記号が除かれ、セディーユ（ç）が変換されると述べています。説明文やSEOの情報も対象です。シートを機械的にインポートすると、ストア上では正しかった文章が悪くなることがあります。開発者は書き出した内容をストアのページと照合し、必要な箇所では承認済みの文言を戻します。ストア運営者は商品名と商用の説明を確認します。

ドキュメントにあるファイルには Endereço do Produto (URL Tray)（商品アドレス、TrayのURL）も含まれます。URLマップのためにこの列を残してください。Trayのアドレスに普遍的な規則を作らないでください。実際に書き出されたアドレスを使い、既存のストアと照合します。原本は編集せずに保管し、変換は識別した作業用コピーで行います。

顧客については、属性付きエクスポートのドキュメントが Vendas > Clientes > Exportar clientes（販売 > 顧客 > 顧客をエクスポート）を示しています。フィルターがあり、あとから通知でダウンロードします。結果は登録データとニュースレターなどの項目を含むCSVです。同意の情報は残し、購入者の全員を自動的にマーケティングの購読者にしないでください。ファイルへのアクセスを制限し、開いた会話に添付しないでください。

注文は Vendas > Listas de pedidos > Exportar pedidos（販売 > 注文リスト > 注文をエクスポート）から出ます。Trayは、このエクスポートには一覧のフィルターとは別の独自フィルターがあると述べています。期間、ステータス、選んだチャネルを記録し、生成したファイルを全履歴と混同しないでください。対応を続けるために必要な、処理中の注文、キャンセル、返品を含めてください。

3. カタログ、顧客、注文を別々の作業としてインポートする

2026年10月19日に読んだShopifyの公式案内は、商品、次に顧客、最後に過去の注文をインポートする、という順序です。この順は、データの関係を保つのに役立ちます。Trayのエクスポートを、そのまま送れるファイルとは見なさないでください。開発者は列を移行先のテンプレートに合わせる必要があります。

カタログでは、移行元の識別子、SKU、バリエーション、価格、在庫、重量、画像、内容を対応づけます。商品そのものと、購入オプションを分けてください。色やサイズを、シートの都合でばらばらの商品にしてはいけません。画像が正しいバリエーションに対応しているか、配送計算に必要なデータが残っているかも確認します。

Shopifyは、テンプレートに定められた見出しの形式と、UTF-8の文字コードを要求します。ドキュメントは、任意項目が空のまま既存商品を上書きすると値が消えることがあると警告しています。運用上の勧めは、残りのデータへ同じ変換を広げる前に、代表的なロットを検証することです。バリエーションがある商品、プロモーション、在庫切れ、長い説明を含めてください。

顧客は、欠けている情報を作らずに項目を対応づけます。Shopifyによれば、顧客CSVは注文履歴をインポートしません。別ストアのパスワードも移しません。ドキュメントの文は “You can't migrate customer passwords from another online store using a CSV.” です。購入者が古いパスワードを使い続けられると約束しないでください。新しいストアで使うアクセスの流れを、案内する前に用意して検証します。

過去の注文には、別の方針が必要です。Shopifyの一般的な案内は、この移行にアプリとAPIを示しており、顧客CSVと同じやり方とはしていません。開発者は、ステータス、金額、明細、移行元の識別がどこへ行くかを示す必要があります。ストア運営者は、履歴をShopifyの中に置くか、外に残した照会で持つかを決め、その違いを範囲に明記します。どちらの場合も、交換、配送、返金に対応できるよう、チームは購入を見つけられる必要があります。

Trayから離れるなら、ストアのURL、商品数、現在のプランを送ってください。まだShopifyストアを作っていないなら、作る前にご相談ください。ストアは開発ストアとして立ち上がり、あなたの名義へ移管できる形態です。

プロジェクトを相談

4. ドメインを接続する前に、古いURLを1件ずつ対応づける

URLマップは検証できる成果物であり、「SEOを見ておく」という漠然とした約束ではありません。Trayから書き出した商品のアドレスから始め、カテゴリ、会社情報のページ、ナビゲーションとストアの記録から見つかったコンテンツで補います。検索とアクセスのデータがあるときは、メニューに出てこない重要なページを見つけるのに役立ちます。

古いアドレスごとに、新しい行き先、対応づけた理由、期待する結果を記録します。残る商品は、対応する商品へ導きます。再編したカテゴリには、クリックした人の意図に合うコレクションが必要です。適切な代わりがないときは、ストア運営者が扱いを決めます。すべてをトップページへ送っても、対応するものがない問題は解けません。

ストア運営者が商売上の対応を承認し、開発者がリダイレクトを実装してテストします。 この分担は、自動化が販売終了の商品を無関係な商品へ送ることを防ぎます。最初の商品選定から外れただけで、繰り返し需要のあるページが消えることも防ぎます。

2026年10月19日に確認したShopifyの公式ヘルプは、リダイレクトをCSVでインポートでき、HTTP 301の使用を説明しています。重要な条件があります。“You can redirect only from broken URLs.” つまり、転送元のパスがShopify上で動くページを出し続けてはいけません。予約されたパスと、クエリパラメータの制限もあります。開発者は、シートのすべての行が動くと決めず、例外を分けてください。

Shopifyの移行ドキュメントが案内するとおり、切り替えの前にリダイレクトを登録します。使える環境で設定を検証し、確定ドメインの確認は切り替えのあとに残します。インポートしたファイルは設定の証拠であり、すべての訪問者がすでに正しい行き先へ着いている証明ではありません。

この作業は壊れたリンクを減らしますが、Googleの順位を固定しません。移行では内容、構造、体験も変わります。検索の面を深めるには、NuvemshopからShopifyへの移行とSEOの注意点の記事を見てください。ここでの違いは、Trayから書き出したデータを使い、行き先をストア運営者が承認することです。

5. テスト注文でテーマ、在庫、配送、決済を確認する

確認は、トップページの見た目だけではなく、購入の実際の経路に沿って行います。ストア運営者は運用を代表する商品を選び、情報、価格、商用ポリシー、見せ方を検証します。開発者はテーマを設定し、バリエーションの選択、カート、在庫なしのメッセージ、予定した連携との接続を確認します。

変更後の在庫がどこから来るかを決めてください。ERPや別のシステムが残高を持つなら、どの登録が優先され、連携がいつ動き始めるかをチームが知る必要があります。規則なしに、手作業のインポートと競合する同期を同時に置かないでください。移行のあいだ、Trayでの販売が、すでにShopifyへ載せた残高を変えることがあります。

配送では、対応地域を代表する住所と、そのストアで重要なケースを検証します。表示された選択肢、金額、お届け日数が、承認した商用ルールと合うかを確認します。テストには、実際の重量とバリエーションのデータを持つ商品を使います。簡略化した登録は、販売のときだけ出る不具合を隠すことがあります。

2026年10月19日に読んだShopifyのテスト注文のドキュメントは、チェックアウト、処理、在庫、配送、通知、税の確認を勧めています。シミュレーションの方法と、実際の事業者での購入のあとキャンセルと返金を行う方法があります。契約した決済に合う方法を選んでください。シミュレーションを、実際の資金決済の証明として扱わないでください。

検証に使った注文と、関係する各システムで何が起きたかを記録します。決済は期待したステータスのままか。残高は正しく変わったか。配送は承認どおりに出たか。チームは注文を見つけて対応を続けられるか。テストが書類、請求、在庫の引当を生むなら、その影響を意識して扱い、当てはまるときは取り消しを確認します。

ストアを公開する前に、テストだけのものを取り除き、実際の販売設定を確認します。ストア運営者は体験と商用条件を承認します。開発者は、各部品がつながっているという技術的な証拠に責任を持ちます。この段階の食い違いは、切り替えを遅らせる理由であり、購入者の苦情を待つ理由ではありません。

6. DNSは最後に切り替え、運用を突き合わせる

最初のエクスポートは、そのあとに起きた販売を捉えません。切り替えの前に、ストア運営者と開発者は新しいデータの扱いを決めます。届いた注文、登録の変更、在庫の変動です。最後の抽出の時点を記録し、それ以降の記録を識別します。誰かが覚えている時刻だけを比較の基準にしないでください。

進行中の注文をどこで完了させるかも決めてください。Trayで始まった購入は、決済確認、発送、対応がまだ残っていることがあります。ストアフロントを変えても、その義務は自動では移りません。チームは、各購入をどのシステムで調べ、更新するかを知る必要があります。新しい請求を発生させたり、同じ商品を再びピッキングしたりしないためです。

そのあとで初めて、開発者がドメインを変更します。使うのは、その時点のShopifyとDNS事業者の設定です。ストア運営者は適切なアクセスを渡し、ドメインを誰が管理するかを確認します。メールのように、移行に含まれないサービスのレコードは残します。既存のゾーンを確認せずに、汎用のDNS手順をコピーしないでください。

切り替えのあと、公開ドメイン、ナビゲーション、リダイレクトの行き先、購入の流れを検証します。通知と連携が、期待した場所へ届き続けているかも確認します。この確認は切り替え前のものとは違います。今度のテストは、顧客がすでに知っているアドレスを通ります。

突き合わせと対応が必要なあいだは、以前の運用のデータと照会手段を残します。Shopifyのトップページが開いたというだけでTrayを閉じないでください。新しい注文を関係するシステムと照合し、移行中に旧環境だけに残った販売を探します。

重大な不具合が出たら、予定していたトラフィックの公開を止め、決めておいた緊急時の手順に従います。販売を突き合わせずに向き先を戻すと、別の食い違いが生まれます。技術的な完了はデータ、購入、ナビゲーションの証拠に依存し、商売上の完了はチームが運用できることに依存します。Loja IntegradaからShopifyへの移行チェックリストは一般的な段階の比較に役立ちますが、ここで述べたファイルとエクスポートの注意はTrayに固有です。

よくある質問

Trayの商品をShopifyへどうインポートするか

必要なバリエーションとステータスを含めて、Trayの管理画面でカタログをエクスポートします。開発者はデータをShopifyのCSVテンプレートに合わせ、文字コード、画像、SKU、価格、在庫を確認し、インポートを広げる前にロットを検証します。直接互換すると決めて、元のシートを送らないでください。説明文とSEO項目も比較してください。Trayのドキュメントは、エクスポート中にアクセントが変わるとしています。

注文履歴は顧客リストに付いてくるか

Shopifyの顧客CSVでは付いてきません。ドキュメントは、この機能が注文履歴をインポートしないと述べています。アプリまたはAPIでの移行か、外部の照会に履歴を残すかを別に決めてください。Shopifyの外に置くなら、依頼する人と顧客対応をする人の両方に、そのことを明確にしてください。Trayから注文をエクスポートしても、データの源は残りますが、移行先へ入った証明にはなりません。

顧客は同じパスワードを使い続けるか

Shopifyは、CSVで別ストアのパスワードを移行できないと述べています。したがって、案内で古いパスワードが続くと約束しないでください。使うアクセスの流れを検証し、新しいストアへの入り方を顧客に説明します。アカウントを手作業で作り直そうとして古いパスワードを求めたり、実際の体験を確認する前に案内を送ったりしないでください。

TrayからShopifyへの移行でGoogleの順位は維持されるか

順位が維持される保証はありません。URLマップ、リダイレクト、重要な内容の保持は避けられる問題を減らしますが、変更は検索の変動の対象のままです。受け入れでは、アクセスできるページと筋の通った行き先を求め、順位の約束は求めません。切り替えのあと重要なページを見守り、壊れたリンクや不適切な対応を直します。

移行を頼む前にShopifyアカウントを作るべきか

先にストアの形態について話してください。現在のドキュメントは、移管できないテスト用の開発ストアと、クライアントへ移すためのストアを区別しています。運用を組み立ててあなたの名義で渡すには、移管できる形態を選ぶ必要があります。Shopifyストアがすでにあるなら、初期の評価でそのことを伝えてください。作業は使える環境を前提にし、習慣で別のストアを開かないためです。

まとめ

TrayからShopifyへ移すには、確認済みのエクスポート、行き先の決まった履歴、切り替え前に処理したURL、DNSを変える前に検証した購入が必要です。ECの移行と構築のプロジェクトでは、ストア運営者が運用として残すものを決め、開発者がデータと流れをどう扱ったかを示します。ストアを評価するには、Trayのストアアドレス、商品数、現在のプランを送ってください。まだShopifyストアを作っていないなら、作る前にご相談ください。提案は、クライアントへの移管を前提にした開発環境でストアを組み、運用を検証し、所有権をあなたの名義へ移すことです。

プロジェクトを相談