多言語サイトのリニューアル｜URL・翻訳・フォームを引き継ぐ判断と移行手順

多言語サイトが古くなったとき、すぐに全部を作り直す必要はあるのでしょうか。最初にすることは、見た目の好みで更新範囲を決めることではなく、残す情報、直す導線、移行するときに失ってはいけないものを整理することです。URL、商品条件、翻訳版、問い合わせ先がそろっていれば、部分改善で解決できる場合もあります。

全面更新を選ぶ場合も、公開中のページを消して新しいサイトを置けば終わりではありません。GoogleはURL変更を伴う移行について、準備、旧新URLの対応表、転送、移行後の確認という流れを説明しています。新しいデザインが表示されたことと、検索や問い合わせの入口を引き継いだことは分けて確認します。Googleのサイト移行資料

この記事で分かることは、部分改善と全面更新を選ぶ判断軸、多言語サイトで引き継ぐ情報、公開前後の検証と費用の整理方法です。紹介する比較表と架空例は編集上の提案です。特定の顧客の成功談、問い合わせ増加の実績、未確認の制作価格を示すものではありません。現在のサイトを壊さず、相談できる資料を作るところから始めましょう。

作り直す前に何を調べるか？

古さを、読者が困る場面へ言い換える

「古い」という印象だけでは、必要な作業が決まりません。スマートフォンで文字が読めない、製品資料が古い、英語の問い合わせ先がない、同じ商品の言語版で条件が違うなど、読者が困る場面へ分けます。色や余白の変更で直るものと、情報の管理方法から変えるものは異なります。見た目を一新しても、仕様の正本が分からない状態は残ります。

実際の公開ページを確認し、ページ名、URL、言語、役割、更新日、確認できた問題を表にします。検索で流入しているページや営業担当が資料として送っているページは、表の中で区別します。アクセスの記録が見られなければ、流入がないと決めつけず、未確認として扱います。古い記事というだけで削除したり、すべての言語版を非公開にしたりしないでください。

表は横にスクロールして比較できます。

管理画面の一覧と、実際に見える状態を分ける

管理画面にページが存在しても、一般の訪問者が読めるとは限りません。反対に、管理者が見ていない古いURLが検索や外部リンクから使われていることもあります。一般公開のURLを開き、本文、画像、資料、フォームへの移動を確認します。管理者のログイン状態と匿名の状態で表示が違う場合は、どの経路で何を確認したかを分けて記録します。

サイトの一覧には、ページだけでなく、PDF、画像から直接開く資料、フォームの完了画面なども含めます。架空の製造会社を例にすると、営業担当が海外へ送っている英語PDFはトップページから見つからなくても重要な資料です。ページの見た目だけを作り直し、このPDFを置き忘れると既存の商談に影響する可能性があります。この例は実案件の事故記録ではなく、調査対象を決めるための例です。

調査の段階では、個人情報や顧客の資料を無関係な制作環境へ複製しないようにします。確認に必要なのが項目名と動作なら、ダミー情報で再現できます。既存データの保管や移行が必要な場合は、対象と扱う担当者を決め、バックアップの所在を確認します。サイト制作のためという理由だけで、すべての顧客情報を制作者へ渡す必要はありません。

部分改善と全面更新をどう選ぶか？

問題の広がりと、直した後の管理で比べる

一部のフォーム、特定言語の翻訳、スマートフォンの表示など、問題の範囲が明確なら部分改善を検討できます。一方、同じ情報が複数の場所で別々に管理されている、ページ構造とURLの関係が追えない、更新のたびに全言語へ手作業が必要といった状態では、構造から見直す余地があります。判断はサイトの年齢だけでなく、問題の広がりと今後の管理方法で行います。

全面更新にも調査、翻訳確認、資料移行、切替後の対応が必要です。「一から作れば安い」「古いサイトは必ず作り直す方が得」とは言い切れません。部分改善でも、基礎構造の問題を何度も補うなら負担が大きくなる可能性があります。実際の見積と対象を比べ、今の問題を直す費用だけでなく、更新を続けるための作業まで並べます。

表は横にスクロールして比較できます。

変えないものを先に決める

新しいサイトを考える会議では、追加する機能が中心になりがちです。しかし、今の相談窓口、検索されている記事、営業で使う資料、他媒体からのリンクなど、残すものも同じくらい重要です。ページを統合するなら、元の用途をどこで受け止めるかを決めます。内容の違うページを、一覧を短くするためだけに同じ場所へ集約しないでください。

架空の例で、日本語と英語に同じ製品一覧があるとします。英語版だけ資料の更新が止まっているなら、まず正しい資料へそろえる改善が考えられます。製品の管理自体が言語別に分裂し、型番や販売範囲まで違っているなら、情報の正本と翻訳の管理を見直す必要があります。どちらも画面を新しくするだけでは、問題の原因に届きません。

受入条件は「洗練されたサイト」ではなく、読者の行動で書きます。スマートフォンで製品条件を読める、各言語から同じ製品へ移動できる、資料の版が一致する、安全なテストで問い合わせの受信を確認できる、といった条件です。合格を判断する人と確認方法も決めます。制作担当の感想だけで完成扱いしないために、依頼時からこの条件を共有しましょう。

段階的な更新で、旧新が混ざる条件を確認する

段階的に更新する場合は、先に変えるページと後で変えるページを決めます。日本語の製品ページだけが新しくなり、英語版が旧構成のまま残るなら、言語切替の対応をどう保つかが課題になります。新しい画面から旧資料へ移るときにも、資料名、対象、言語が分かるようにします。すべてを同時に変えないことと、旧新の関係を管理しなくてよいことは別です。

架空例では、問い合わせフォームを先に修正し、製品ページは後から整理する順序を選ぶ場合があります。このときフォームの変更に必要なリンクだけを直し、製品URLまで一括で変える必要はありません。反対に、製品の分類を先に変えるなら、フォームから参照する製品名や資料との対応が重要です。工程を分けるときは、各段階で公開状態が成立するかを判断します。

制作者へ渡す資料にも、今回の対象外を示します。対象外は忘れてよいものではなく、今の版を維持するものです。触らない予定のページが共通メニューや共通設定の変更で影響を受ける場合があるため、主要な導線だけは確認に含めます。変更したページだけを点検して、既存のページへの影響を見落とさないようにしましょう。

URLと検索情報をどう引き継ぐか？

旧URLと新URLを一対一で対応させる

URLを変える場合は、旧ページの役割に対応する新しいページを決めます。すべての旧URLを新トップページへ送ればよいわけではありません。製品の仕様を見ようとした人が会社案内へ送られると、目的の情報が見つからなくなります。移行表には旧URL、新URL、言語、内容の対応、転送の要否、確認結果を持たせます。

Googleの移行資料は、URLの対応付けと旧新の転送、新ページの準備、移行後の確認を段階として説明しています。本稿ではその流れを、多言語サイトの作業分担へ置き換えて考えます。検索順位や検索登録が保たれることを保証するものではありません。URL変更には一時的な変動もあり得るため、公開画面と検索上の結果は分けて観測します。

表は横にスクロールして比較できます。

新ページの200表示だけでは移行完了にならない

新URLが開くこと、旧URLから適切に転送されること、ページが自分の正しいURLを示していることは別の確認です。正規URLの設定が旧版を指したままなら、見た目が新しくても検索向けの情報が食い違います。言語版の対応、内部リンク、サイトマップも新しい構造にそろえます。管理画面へ入力した値だけでなく、公開されたHTMLで確認します。

日付付きURLを短くする、製品分類を変える、言語の階層を統一するといった変更も同じです。文字列から日付やフォルダを消すだけでは、旧URLを使っている人の入口は守れません。先に固定ページや資料、別言語のルートとの衝突を確認します。短いURL自体を順位が上がる条件と考えず、読者が分かりやすく管理できる構造として判断してください。

架空の対応表では、旧日本語製品ページを新日本語製品ページへ、旧英語ページを新英語ページへ結びます。新英語版がまだ完成していないからと、日本語版へ一律転送するのは慎重に判断します。読者の言語と目的が変わるためです。公開できない言語版がある場合は、何を残し何を説明するかを決め、未完成ページへのリンクを「対応済み」として増やさないようにします。

変更前には現在の設定と公開ファイルを保存し、戻す対象を決めます。切替後に旧URLが開かなくなったとき、何をどの版へ戻すかが分からなければ復旧に時間がかかります。戻せることはバックアップがあることだけでなく、復元する人、対象、確認手順が決まっていることです。転送設定や本番の変更は、合意した対象と承認範囲で少しずつ進めます。

対応表そのものの不備を先に見つける

本稿では架空のパスを使い、移行表を点検する小さなローカル確認を行いました。対象は、同じ旧URLに複数の転送先がある、一つの旧URLの転送先が未記入、到達先が再び旧URLを指して往復する、言語が違うページへ割り当てられる、という四つの不備です。期待した検出結果を先に置き、合成データで該当する行を特定できるかを確認しました。

この確認は表の整合性を調べたもので、実際のサーバー転送や検索結果を検証したものではありません。実URLへの変更、外部送信、本番の設定変更は行っていません。表に不備がなくても、公開先の内容、状態、正規URLは実際の公開環境で確かめる必要があります。準備段階の検査と本番での検証を分けて記録するための例です。

対応先がないページは、無理に似た名前のページへ結びません。残す内容があるなら新しい受け皿を作る、不要か判断できないなら保全して調べる、といった次の工程を決めます。確認できない行を消して表を完成に見せることは避けてください。

翻訳と商品条件をどうそろえるか？

旧翻訳を全部捨てる前に、使える情報を選ぶ

リニューアルのたびにすべてを翻訳し直す必要があるとは限りません。正確で現行の内容と一致する文章は、引き継げる可能性があります。反対に、読みやすくても旧製品の仕様や販売条件が混ざっているなら修正が必要です。文章の流暢さと情報の正しさを分け、日本語の正本、旧翻訳、今回の変更点を並べて確認します。

確認するのは本文だけでなく、画像内の文字、資料、ボタン、エラーメッセージ、自動返信も含まれます。日本語本文だけを修正し、フォームの完了画面に古い納期や連絡先が残ると、読者へ矛盾した説明が届きます。言語別のページ一覧と、共通で使う文言の一覧を作り、どの情報をどこで更新するかを決めます。

表は横にスクロールして比較できます。

言語ごとの約束を同じにする

「相談可能」「目安」「対応地域内」といった条件が、翻訳版で無条件の確約に変わっていないか確認します。料金、納期、保証、利用条件は特に重要です。翻訳担当へ「自然にしてください」とだけ渡すと、曖昧な原文が強い表現へ整えられてしまう場合があります。確定していること、判断待ち、公開できないことを分けて伝えます。

更新後も同じ情報を保つには、商品情報の責任者と翻訳の責任者を明確にします。制作会社が文章を整えても、提供できるサービスや契約条件を勝手に決めることはできません。仕様の正本が変わったとき、どの言語へ修正を展開し、誰が確認して公開するかを決めます。担当交代に備え、関連する資料と更新履歴も残してください。

生成画像や写真を入れ替える場合は、見栄えだけでなく、旧版で伝えていた条件との関係を確認します。実際の商品の写真と異なる図を、実物の紹介として置き換えないようにします。概念図には説明上の役割を持たせ、必要な条件はHTML本文にも残します。画像を読めない環境でも、商品名、用途、注意事項、相談方法が分かる構成にします。

翻訳版の確認は、編集ソースの比較だけで終えず公開画面でも行います。改行、表の幅、文字の欠け、フォント、言語切替後の到達先を確認します。別のページを表示しているのにボタンだけが元の言語を示す、といった不整合も点検対象です。確認できていない言語を、ほかの言語と同じ品質で確認済みと報告してはいけません。

フォームと公開切替をどう確認するか？

表示、送信、受信を別々に確かめる

問い合わせフォームが見えるだけでは、相談を受け付けられるとは限りません。入力内容の確認、送信結果、通知先の受信、必要な自動返信を分けます。テストする場合は安全な内容と確認用の受信先を決め、実在する顧客の情報を使わないようにします。承認されていない送信先へ試験メールを送る必要はありません。

公開前の確認環境と公開後では、設定や経路が異なる場合があります。確認環境で成功しても、本番の受信先や公開URLで未確認のままなら、その範囲を残します。ボタンの押下、送信処理の受付、メールが届いたことを一つの「成功」でまとめず、何を確認したかを記録します。結果が不明なときは、実状態を調べる前に何度も送信しないでください。

表は横にスクロールして比較できます。

切替の間に変更された内容を取り込む

制作期間中も旧サイトで商品情報や相談が更新されるなら、いつのデータを新サイトへ移すかを決めます。作り始めた日のコピーだけで公開すると、その後の修正が失われます。旧サイトをいつまで編集できるか、変更した担当者がどこへ記録するか、公開直前にどの差分を取り込むかを整理します。確認していない最新状態を、移行済みと扱わないことが重要です。

架空の例で、旧サイトの英語フォームの受信先が制作中に変わったとします。新サイトが古い受信先のまま公開されると、表示の確認だけでは気づけません。切替前の確認票に連絡先や通知先の照合を含め、変更履歴と比べます。公開後も安全なテストで実際の受信を確かめれば、設定しただけで完了とする誤りを減らせます。

戻す判断も先に決めます。旧URLの広範な失敗、主要商品の本文欠落、問い合わせ経路の障害など、読者の利用へ直接影響する問題は、予定どおり公開したことを優先せず対応します。一方、軽微な余白の違いなら、その場で全面的に戻す必要があるとは限りません。問題の大きさ、影響範囲、修正と切戻しのどちらが早く安全かを判断できるようにします。

公開直後に修正を重ねる場合も、誰が何を変更したかを残します。複数の担当者が同じ設定を直すと、原因が分からなくなったり、直した箇所を元に戻したりします。担当範囲を分け、変更後は対象の公開URLを再確認します。制作の完了報告には、保存、反映、一般公開の確認を分けて記載しましょう。

公開後の不具合と費用をどう管理するか？

見積を、作る費用と移す費用に分ける

リニューアルの費用はページ数だけでは比べられません。現状調査、構成、原稿、翻訳確認、画像、資料移行、URL対応、フォームの確認、公開後の対応など、どこまで含むかで変わります。未確認の相場を一律の金額として置くより、自社の対象を項目別に伝え、同じ条件で見積を比較します。契約に含まれない作業が残るなら、誰が担当するかを決めます。

表は横にスクロールして比較できます。

成果を測る前に、比較できる状態を残す

公開前の状態を記録していなければ、何が変わったかを説明しにくくなります。主要ページ、公開URL、言語別の情報、フォームの受信確認、利用状況のうち取得できるものを保存します。公開後に問い合わせが増えても、広告や季節など他の要因があれば、リニューアルだけの効果と断定しません。記録していない数字や架空の事例を、成果の証明として補わないでください。

問い合わせ内容の分類は、件数だけでは見えない問題を探す助けになります。仕様を確認する質問が続くなら商品ページ、対応地域に関する誤解があるなら冒頭の対象説明、返信が止まるなら受付後の引継ぎを確認します。実際の記録を扱う場合は必要な範囲に限定し、個人や企業を特定する内容を公開サンプルへ混ぜないようにします。

公開後の点検日は、制作の契約や運用体制に合わせて決めます。「定期的に確認する」だけでは、担当者が変わったときに作業が消えます。何を、誰が、どの証拠で確認するかを決め、障害があったときの連絡先も残します。更新がなくても、公開URL、問い合わせ経路、資料が使える状態かは別に確かめる必要があります。

既存の記事や資料を移した後も、編集できる原稿と公開版の対応を保ちます。修正依頼が来たとき、どのファイルを直すべきか分からなければ更新が遅れます。正本、公開先、最終確認日を入口の記録へまとめ、不要と確認していない旧資料を勝手に削除しないようにします。履歴は使い続けるページと区別して保管します。

追加作業の判断と引継ぎを決める

調査を進めてから古い資料や別言語のフォームが見つかることもあります。そのたびに口頭で追加すると、見積の対象と完成条件が分からなくなります。追加する理由、必要な作業、既存工程への影響、費用や公開時期の変更をまとめ、合意した範囲へ戻します。公開に不可欠な修正と、後から追加できる改善を区別すると、必要な確認を省略せずに進められます。

引継ぎでは、管理画面の使い方だけでなく、仕様情報の正本、翻訳の更新方法、資料の公開場所、障害時の連絡先も渡します。利用するサービスや認証の権限は必要な範囲にし、秘密情報を原稿や公開ファイルへ入れないことが前提です。操作説明を受けたことと、実際に担当者が更新・確認できたことも分けて扱います。

完成報告に未確認項目がある場合は、単に「保留」と書かず、対象と理由、次に確認する人を残します。たとえば一つの言語で受信が未確認なら、その経路だけを具体的に示します。全体が完成したと誤解させず、すでに確認済みの作業を最初からやり直さないためにも、到達点が分かる記録が必要です。

よくある質問

古いサイトは必ず全面リニューアルすべきですか？

年齢だけでは判断できません。表示、情報の正確さ、管理方法、相談の導線を調べ、部分改善で解決できるかを比較します。全面更新を選ぶ場合も、移行と公開後の確認まで対象に含めます。

URLは短くした方がSEOに有利ですか？

短さだけを順位の条件にはできません。変更する場合は旧新の対応、適切な転送、正規URL、内部リンクなどの確認が必要です。読者の入口を失わないことを優先し、日付や階層だけを削らないでください。

旧サイトの翻訳は全部やり直しますか？

現行の内容と一致するかを確認して判断します。原文の変更、旧仕様、対応範囲の違いがあれば修正します。本文だけでなく資料、ボタン、自動返信も点検対象です。

制作費用を比べるには何を用意しますか？

ページと資料の一覧、言語、残すURL、問題のある導線、翻訳の確認担当、公開後の運用範囲をまとめます。同じ対象で見積を比べ、調査・移行・検証が含まれるかを確認します。

公開できたら完了ですか？

公開は一つの工程です。匿名アクセス、スマートフォンとPC、旧URL、画像、リンク、問い合わせ受信など、対象に応じた実確認が残ります。検索結果や売上の成果も、公開の成功とは別に記録します。

まず残すものを一枚にまとめる

リニューアルで最初に作るべき資料は、追加機能の一覧だけではありません。今使われているURL、正しい商品情報、言語版、資料、相談窓口を並べ、残すものと直すものを分けます。そのうえで部分改善か全面更新かを選べば、見た目の変更に必要な情報の移行が埋もれにくくなります。

関連する読み物として、多言語SEOのhreflangとcanonical確認、多言語サイトの記事一覧も参照できます。記事のURLや公開状態は制作時に照合し、本文の根拠と相談の入口を役割別に使いましょう。

タゲンゴでは、既存の多言語サイトの構成やリニューアル範囲の相談を受け付けています。現在のURL、困っている場面、必要な言語を整理し、リニューアルの相談窓口へお知らせください。機密資料や顧客情報は初回から送らず、共有が必要な範囲を先に確認してください。検索順位や問い合わせ数の増加を保証するものではありません。

出典・運営情報

• 公式資料：Google Search Central「How to move a site」。URL変更を伴う移行の準備・対応表・転送・監視の説明を参照。
• 根拠確認日：2026年10月30日。2026年11月2日向けの先行原稿で、公開前にリンク・仕様の再確認が必要です。
• 執筆・運営：タゲンゴ。実務表は編集提案、会社例は架空です。架空の売上、顧客実績、価格、現地取材、専門家監修は採用していません。