多言語WordPressサイトでは、WordPress本体やプラグインを更新するだけでは安定運用を維持できません。日本語ページは正常でも英語ページだけが404になる、原文の変更が翻訳ページへ反映されない、言語切り替えやフォームが一部の言語で動かないといった問題が起こり得ます。技術更新に加え、翻訳差分、言語別の重要導線、検索設定、復旧手順まで管理する必要があります。
この記事では、多言語サイトに必要な保守作業と責任分担を整理し、社内運用の工数と外注見積もりを比較する方法を解説します。自社に残す業務と外注する業務を分け、同じ条件で保守費用を比較できるようになります。

多言語サイトの保守では、翻訳、技術更新、検索設定を別々に扱わず、変更記録と責任分担を含めて継続管理します。
多言語サイトの保守が単言語サイトと違う3つの理由
多言語サイトの保守では、技術的にページが表示されるかだけでなく、各言語の情報が最新か、重要な導線が機能するか、検索エンジンに意図した言語URLが伝わるかを確認します。単言語サイトとの主な違いは次の3点です。
翻訳の鮮度を保つには原文変更の記録が必要
日本語の製品仕様、価格、営業時間、利用条件などを更新しても、翻訳ページが自動的に同じ内容になるとは限りません。原文だけが更新され、英語や中国語では古い情報が掲載され続けることがあります。
この問題を防ぐには、原文の変更箇所、翻訳依頼の状態、校正担当者、公開承認者、公開日を追跡できる記録が必要です。技術保守の担当者は変更箇所の把握や公開状態の確認を担えますが、訳文の正確性、用語の選択、法務・営業上の妥当性は、翻訳担当者や事業責任者が判断します。
多言語化の方式を検討している場合は、先にWordPressの多言語プラグイン比較で、翻訳データの持ち方や運用方法の違いを確認してください。
更新後は多言語機能との組み合わせを検証する
確認対象は、多言語プラグイン単体ではありません。WordPress本体、テーマ、PHP、フォーム、SEO、キャッシュ、会員機能、EC機能などとの組み合わせで動作が変わる可能性があります。
更新テストでは、既定言語のトップページだけでなく、言語別URL、言語切り替え、問い合わせフォーム、予約、資料ダウンロード、カートや決済など、事業上重要な導線を言語ごとに確認します。更新前のバックアップと検証環境を用意し、合格条件を決めてから本番へ反映することが基本です。
言語URLと検索設定をまとめて管理する
多言語サイトでは、言語別URL、hreflang、canonical、サイトマップ、リダイレクト、言語切り替えリンクの整合性が重要です。Googleの多言語サイト向けガイドでは、言語ごとに異なるURLを使用し、利用者がリンクから言語を選べる構成が推奨されています。
言語別URLが存在すること自体は、重複コンテンツ違反を意味しません。問題になるのは、hreflangが示すURLとcanonicalが矛盾する、サイトマップに旧URLが残る、利用者や検索エンジンが特定言語へ到達できない、といった不整合です。URLやテンプレートを変更したときは、これらを一組の設定として確認します。
多言語サイトの運用で起きる5つのトラブル

症状ごとに設定をすぐ変更するのではなく、記録、確認、切り分け、検証、本番反映の順に進めると影響範囲を見極めやすくなります。
ここでは、多言語WordPressで起こり得る5つの想定例を取り上げます。原因はサイト構成や利用製品によって異なるため、症状だけで設定を変更せず、観察結果を記録して次の確認先を選ぶことが重要です。
変更や復旧を始める前に、現在のデータ、設定値、WordPress・テーマ・プラグイン・PHPのバージョン、アクセスログとエラーログ、利用可能なバックアップ世代を記録します。侵入や改ざんが疑われる場合は、正常なバックアップを現在のデータで上書きしないでください。復元、侵入原因の除去、再発防止は別の作業として扱います。
変更や復旧を始める前に、現在のデータ、設定値、WordPress・テーマ・プラグイン・PHPのバージョン、アクセスログとエラーログ、利用可能なバックアップ世代を記録します。侵入や改ざんが疑われる場合は、正常なバックアップを現在のデータで上書きしないでください。復元、侵入原因の除去、再発防止は別の作業として扱います。
更新後に英語ページが404になる
想定例1:プラグイン更新後、英語ページだけが404になる
- 症状: 日本語ページは開く一方、英語の固定ページやカテゴリーが404になります。直接URLは開けるものの、言語切り替えリンクから移動した場合だけ失敗することもあります。
- 確認箇所: 影響を受けたURL、発生時刻、直前の更新、ステータスコードを記録し、直接URLと切り替えリンクの結果を分けて確認します。あわせて、パーマリンクと言語URLの設定、ページ間の関連付け、リダイレクト、キャッシュやCDNの状態、エラーログを確認します。
- 慎重な対処: 直接URLも404なら、URL設定、ページの公開状態と関連付け、ルーティングを技術担当へ渡します。直接URLは開き、切り替えリンクだけ失敗するなら、リンクが指すURLと言語判定、キャッシュの影響を確認します。設定とログを保存したうえで、検証環境または影響を限定できる条件で再現し、修正候補を試してから本番へ反映します。
- 予防: 更新後の合格条件に、各言語の代表ページ、下層ページ、言語切り替え、フォームの確認を組み込みます。安全なプラグイン更新の進め方も参照してください。
想定例2:PHPなどの更新後、中国語ページの表示が崩れる
- 症状: 一部の文字が化ける、指定した中国語フォントが表示されない、特定ページだけレイアウトが崩れるといった状態です。
- 確認箇所: 問題のURL、文字列、画面の記録に加え、管理画面上の保存文字列、配信されたHTML、別端末や未キャッシュ時の表示を比較します。保存データと出力時の文字コード、データベース接続、
mbstringなどのPHP拡張、フォント配信、テーマのCSS、キャッシュ、エラーログも確認します。 - 慎重な対処: 管理画面上の保存文字列も崩れていれば、保存データやデータベース接続側を確認します。HTML内の文字が正しく見た目だけ崩れる場合は、フォント配信やCSS側を確認します。特定端末やキャッシュ済みの表示だけが崩れる場合は、ブラウザ、CDN、キャッシュの条件を技術担当へ伝えます。PHP更新だけを直接の原因と決めつけず、検証環境で修正候補を試します。
- 予防: 更新前後のテストに、中国語など非ラテン文字を含む代表ページと主要ブラウザでの表示確認を加えます。
意図した言語URLが検索結果に出ない
想定例3:hreflangとcanonicalが整合せず、別の言語URLが表示される
- 症状: 検索結果に意図した言語ページが出ない、異なる地域向けURLが選ばれる、インデックス状況の確認が必要になる状態です。
- 確認箇所: 対象となる検索語、表示されたURL、意図したURL、確認日時を記録します。そのうえで、各URLのステータスコード、自己参照canonical、
hreflangの自己参照と相互参照、noindex、サイトマップ、リダイレクト、言語切り替えリンクをURL単位で照合します。 - 慎重な対処: 意図したURLが404、リダイレクト、
noindexなら、まず到達性とインデックス許可を確認します。URLは開けてもcanonicalが別言語を指している場合はcanonicalとの整合性を、canonicalが正しくてもhreflangの参照先や相互参照が欠ける場合は言語別URLの対応関係を確認します。Googleのcanonicalに関するガイドに沿ってシグナルをそろえ、修正内容と対象URLを記録してSearch Consoleで経過を確認します。 - 予防: URL、翻訳ページ、テンプレート、多言語設定、サイトマップを変更したときに、言語別URLの対応表を使って検索設定を確認します。
言語切り替えと翻訳更新が止まる
想定例4:キャッシュによって言語切り替えが固定される
- 症状: 切り替えボタンを押しても元の言語へ戻る、別の利用者向けの言語が表示される、直接URLと画面遷移で結果が異なる状態です。
- 確認箇所: 対象URL、選択した言語、遷移先URL、Cookieの有無、ブラウザやログイン状態、発生時刻を記録します。言語がURL、Cookie、ブラウザ設定のどれで判定されるかを整理し、キャッシュプラグイン、サーバーキャッシュ、CDN、ブラウザキャッシュの影響を分けます。
- 慎重な対処: 直接URLでは正しい言語が開き、切り替え操作だけ失敗する場合は、切り替え先URLやCookieによる言語判定を確認します。未キャッシュ時は正常で、再訪時や別利用者で誤表示になる場合は、配信されるキャッシュの条件を確認します。すべての経路で同じ誤表示になる場合は、ページの言語関連付けやURL設定も確認対象です。使用中の製品を特定し、公式資料に基づいて検証環境で対処します。
- 予防: キャッシュ設定の変更時に、直接URL、言語切り替え、未ログイン・ログイン状態、フォーム、予約や購入導線をテストし、条件と結果を残します。
想定例5:翻訳ページが3年間更新されていない
- 症状: 原文では製品仕様や問い合わせ先が変わっているのに、翻訳ページには古い情報が残っています。
- 確認箇所: 原文と翻訳の最終更新日、ページ一覧、翻訳待ち件数、承認者、用語集、過去の依頼・公開記録を確認します。原文変更、翻訳依頼、翻訳完了、承認、公開のどの段階で止まっているかを特定します。
- 慎重な対処: 原文変更の記録がなければ、更新履歴とページ台帳から差分を整理します。依頼前で止まっていれば翻訳対象と優先度を決め、翻訳済みで未承認なら承認者と期限を確認し、承認済みで未公開なら公開対象と言語を確認します。価格、仕様、法務、安全情報、問い合わせ、採用など影響の大きいページから期限付きのバックログにします。
- 予防: 原文変更を起点に翻訳依頼を発行し、対象言語、担当者、期限、校正、事業承認、公開確認までの状態を記録します。Web担当者は滞留段階と最終更新日を一覧にし、翻訳担当者や承認者へ引き継げる状態を保ちます。
多言語保守で必要なタスク一覧

定期点検に加え、本体・PHP・URL・キャッシュなどを変更するたびに、バックアップ確認、検証、承認、反映後確認を行うことが重要です。
多言語サイトの保守は、定期作業と変更をきっかけに行う作業を組み合わせます。次の表は一般的な運用モデルです。自社サイトの重要URL、更新頻度、承認体制に合わせて対象を決めてください。
| 頻度・契機 | 主な作業 | 主な責任者 | 完了記録 | 実施条件 |
|---|---|---|---|---|
| 日次 | 対象とした言語URL、問い合わせなどの重要導線、監視アラートを確認 | 技術担当 | 監視結果、障害チケット | 対象URL、アラート受信者、目視確認の範囲を定義 |
| 週次 | セキュリティ・更新情報と、原文変更に対する翻訳待ちを確認 | 技術担当、編集担当 | 更新候補一覧、翻訳キュー | 差分を把握する台帳やチケットを用意 |
| 月次 | 検証環境で本体・テーマ・プラグイン・PHPの更新候補と互換性をテスト | 技術担当 | テスト結果、変更記録、承認記録 | 対象機能と言語別の合格条件を設定 |
| 四半期 | hreflang、canonical、サイトマップ、言語リンク、主要ページを点検 | 技術・SEO担当 | URL監査記録、修正履歴 | 対象URLと監査の深さを決定 |
| 年次 | メジャー更新に備え、構成、権限、担当者、復旧承認者を棚卸し | 技術・事業責任者 | 年間計画、責任分担表 | サポート期限や事業計画を反映 |
| リリース・変更時 | バックアップ確認、検証、言語別導線の確認、承認、本番反映後の観察 | 技術担当、公開承認者 | 変更申請、テスト証跡、承認記録 | 本体・PHP・URL・テンプレート・キャッシュなどの変更時に実施 |
重大な脆弱性への対応や、必要な更新検証を年次点検まで待つ運用にはしません。変更の緊急度と影響を評価し、検証、承認、反映の記録を残します。より広い点検項目はWordPress保守チェックリストでも確認できます。
コンテンツと公開を管理する役割
コンテンツ・公開管理で決める担当
原文変更と翻訳状態の記録
編集担当者が変更ページ、重要度、翻訳依頼、期限、公開状態を追跡します。
翻訳とネイティブ確認
翻訳担当者が訳文を作成し、必要な言語確認と用語統一を行います。
事業・法務上の承認
事業責任者が価格、仕様、契約、安全情報などの妥当性を判断します。
公開承認
公開責任者が対象言語、公開日時、確認結果を承認します。
復旧承認と事後確認
障害時に復元の可否を判断し、復旧後の内容と再発防止を確認します。
技術的な継続性を守る役割
技術継続性で決める担当
更新準備と検証環境での確認
対象バージョン、影響機能、バックアップ、テスト結果を記録します。
言語別の重要導線テスト
対象URL、言語切り替え、フォームなどの合否を証跡として残します。
URLと検索設定の確認
hreflang、canonical、サイトマップ、リダイレクトの整合性を確認します。
障害の切り分けと連絡
症状、時刻、ログ、変更履歴を整理し、適切な担当へ引き継ぎます。
サーバー・基盤担当との連携
PHP、データベース、CDN、DNSなど基盤側の調査が必要な場合に連携します。
自社運用 vs 専門保守の費用対効果

外注費は社内工数の単純な代替ではありません。技術保守、翻訳・承認、スポット作業を分け、同じ条件で比較します。
費用を比べるときは、月額料金だけでなく、現在社内で使っている時間と外注後も残る業務を明らかにします。以下は、日本語を含む言語数を基準にした月間工数の想定例です。実測平均や工数削減の保証ではありません。
想定には、技術確認、差分整理、翻訳依頼の調整、公開確認を含みます。翻訳文の作成、ネイティブ校正、多言語プラグインなどのライセンス費用は含みません。
| 作業 | 2言語 | 3言語 | 5言語以上 |
|---|---|---|---|
| 更新候補の整理・変更記録 | 3時間 | 4時間 | 6時間 |
| 検証環境での更新・互換性確認 | 5時間 | 7時間 | 12時間 |
| 言語URL・重要導線の確認 | 4時間 | 7時間 | 14時間 |
| 差分整理・翻訳依頼調整・公開確認 | 5時間 | 10時間 | 18時間 |
| 検索・キャッシュ確認と報告 | 3時間 | 7時間 | 10時間以上 |
| 想定合計 | 20時間 | 35時間 | 60時間以上 |
| 時間単価3,000円の月額換算 | 60,000円 | 105,000円 | 180,000円以上 |
| 年額換算 | 720,000円 | 1,260,000円 | 2,160,000円以上 |
計算式は「月間工数×時間単価」です。たとえば2言語では20時間×3,000円で月額60,000円、月額60,000円×12か月で年額720,000円となります。実際に比較するときは、自社のページ数、更新頻度、対象とする言語別導線、確認の深さを当てはめて工数を置き換えます。
外注後も、翻訳の承認、商品・法務上の判断、公開可否の決定などは社内に残ります。そのため、外注費と想定社内費の差額をそのまま削減額とはみなせません。見積もりは、次の5つの条件をそろえて比較します。
- 継続保守の月額と年額、初期費用、契約期間
- 外注後に残る社内工数と、翻訳・ネイティブ校正の費用
- 多言語プラグインなどのライセンスとサーバー保守オプション
- URL・検索設定などの監査範囲と、バックアップからの復旧条件
- 税区分と、単発調査・復旧・改修などのスポット作業条件
継続保守、単発の原因調査、機能追加や大規模改修は、契機も成果物も異なります。各社の見積もりで作業区分と対象範囲をそろえると、月額の高低だけに左右されず、社内負担を含めた年間費用を比較できます。
WPセンターの多言語サイト保守の対応範囲
多言語サイトの技術的な継続性を整えるうえでも、WordPress本体や周辺機能を安全に更新し、バックアップと監視を継続することが土台になります。WPセンターでは、次の一般保守を提供しています。詳細な条件は公式FAQをご覧ください。
| 提供内容 | 対象・条件 |
|---|---|
| 検証環境での更新 | WordPress本体、テーマ、プラグイン、PHPを検証環境で確認してから更新します。 |
| 更新に起因する不具合の解消 | 更新作業によって生じた不具合の解消まで一般保守の対象とします。 |
| 定期バックアップと復旧 | バックアップは月次を基本に、希望に応じて調整します。緊急時のバックアップからの復旧は原則1営業日以内です。 |
| 稼働監視と改ざんチェック | ツールによる24時間365日の稼働監視と、改ざんチェックを行います。 |
| サポートと月次報告 | 電話・メール・Slackなどによる回数制限のないサポートと、月次の作業報告を提供します。 |
| サーバー保守 | オプションとして提供します。 |
更新前の検証、不具合解消、バックアップと復旧を継続して組み合わせることで、更新作業だけで終わらない技術保守を行います。緊急時の「原則1営業日以内」は、バックアップからの復旧に適用する条件です。
業種・言語数別の運用改善ケース3つ
次の3件は、業種と言語数による違いを考えるための想定例です。実在する顧客事例や改善実績ではありません。
製造業2言語:仕様・PDF・問い合わせを同期する
- 課題: 日本語と英語で製品仕様、PDFカタログ、販売店情報、展示会情報の更新時期がずれやすくなります。
- 運用対策: 仕様変更を翻訳依頼の起点とし、製品ページ、ダウンロード、問い合わせフォームをリリースごとに確認します。技術確認と仕様内容の承認担当を分けます。
- 評価指標: 重要ページの翻訳待ち件数、製品URLの確認率、PDFリンクと問い合わせフォームのテスト完了、承認待ち日数を追跡します。
観光・サービス3言語:期限のある情報を優先する
- 課題: 営業時間、季節キャンペーン、予約条件、休業案内が頻繁に変わり、一部言語だけ古い情報になりやすい運用です。
- 運用対策: 期限のあるページを優先し、言語別ランディングページ、予約・問い合わせ導線、確認メッセージ、言語切り替えを変更時に確認します。
- 評価指標: 重要導線のテスト完了率、言語切り替えの障害件数、翻訳待ち件数、検索状態の確認記録を用います。
EC5言語以上:購入導線をリスクに応じて検証する
- 課題: 商品、在庫、配送、決済、クーポン、キャッシュの組み合わせが増え、すべてを同じ深さで確認することが難しくなります。
- 運用対策: 言語ごとに代表商品と重要な購入経路を定め、検証環境で商品表示、カート、決済直前までの導線、メール表示をリスクに応じて確認します。
- 評価指標: 商品ページの到達確認、カート・購入導線のテスト完了、リリース後の不具合件数、翻訳待ち、復旧手順の確認結果を記録します。
料金プランと初回相談の流れ
WPセンターの料金は、料金プランで案内しています。Standardは月額44,000円、Customは個別見積もりです。初期費用は0円、契約期間は3か月からです。月額料金、初期費用、契約期間はそれぞれ別の条件として扱い、税区分や個別要件に基づく費用は見積書で確認します。
初回相談から見積もり条件をそろえる5つの手順
- 非機密情報で現在の状況を伝える
サイトURL、言語数、主な課題、希望時期を相談フォームから送ります。パスワード、秘密鍵、APIキーなどの認証情報はフォームへ記載しません。
- 技術環境と運用方法を整理する
WordPressとPHPのバージョン、テーマ、主要プラグイン、ホスティング、検証環境、バックアップ、更新頻度、翻訳の進め方を一覧にします。
- 重要導線と責任分担を定義する
各言語で守るべきページ、フォーム、予約、ダウンロード、購入導線を示します。技術確認、翻訳、校正、事業承認、公開承認、復旧承認の担当者も決めます。
- 依頼する作業を区分する
継続保守、単発の原因調査、機能追加や改修、翻訳・編集作業を分けます。区分が異なる作業を一つの月額料金として比較しないことが重要です。
- 見積条件と安全な共有方法を確認する
月額・年額、初期費用、税区分、契約期間、残る社内工数、ライセンス、オプション、監査、復旧条件、スポット作業を確認します。認証情報が必要になった場合は、合意した安全な方法で共有します。
相談前に整理する情報
- サイトと言語構造
サイトURL、日本語を含む言語数、言語別URLの形式、ページ数、主なコンテンツ種別を整理します。 - 技術環境
WordPress、PHP、テーマ、主要プラグイン、多言語プラグイン、サーバー、キャッシュやCDN、検証環境を記録します。 - 重要な言語別導線
問い合わせ、予約、資料ダウンロード、会員登録、カートなど、停止時の影響が大きい導線を挙げます。 - 翻訳・確認・公開の流れ
原文変更、翻訳、ネイティブ確認、事業承認、公開承認の担当者と記録方法を整理します。 - バックアップ・障害履歴・見積条件
バックアップ世代、復旧承認者、過去の障害、希望する作業区分、月額・年額・税区分・オプションの確認欄を用意します。変更や復旧前には現状、ログ、バージョン、バックアップ情報を保全し、フォームへ認証情報を送らないでください。
多言語WordPress保守のよくある質問
Q. 技術保守、翻訳確認、事業承認はどう分担すればよいですか?
技術担当は更新、バックアップ、動作確認、ログ、障害切り分けを担います。翻訳担当は訳文と用語を確認し、事業責任者は価格、仕様、法務、安全情報などの妥当性と公開可否を判断します。一つの担当者へ曖昧に集約せず、作業ごとに承認者を決めると停滞を防げます。
Q. 翻訳の更新漏れを追跡するには、何を記録すればよいですか?
原文の変更ページと変更日、翻訳依頼日、対象言語、翻訳状態、確認者、承認者、公開日を記録します。CMSの改訂履歴だけで足りない場合は、ページ台帳やチケット管理を組み合わせます。
Q. ツールによる24時間365日監視では何が分かりますか?
設定した監視対象の稼働状態や改ざんの兆候を継続的に確認する仕組みです。ページがHTTP 200を返していても、誤った言語表示、フォーム不調、翻訳の古さ、表示崩れが残る場合があります。そのため、監視と手動の機能確認は分けて設計します。
Q. WPMLの翻訳メモリとWordPressサイトのバックアップは同じですか?
同じではありません。WPMLとAdvanced Translation Editorを使う場合、翻訳メモリは完了した訳文を同じ言語ペアで再利用する仕組みです。サイトバックアップはWordPressのファイルやデータベースを復元するためのものです。[WPMLの翻訳メモリに関する解説](https://wpml.org/documentation/translating-your-contents/how-wpml-keeps-track-of-your-translations/)も踏まえ、翻訳メモリ、用語集、アカウント権限とサイトのバックアップを別々に管理します。
Q. 継続保守と単発作業を比べる前に何を整理すべきですか?
定期更新、監視、バックアップ、報告などの継続作業と、原因調査、復旧、機能追加、大規模改修などの単発作業を分けます。そのうえで、対象URL、言語別テスト、復旧条件、残る社内工数、翻訳・校正、ライセンス、オプション、税区分を同じ条件で比較します。
多言語サイトの保守範囲を決めるには、言語数だけでなく、重要な導線、翻訳承認の流れ、技術構成、復旧時の責任分担を整理することが出発点です。



