サイトリニューアル事例:宮崎の運送会社ドーズキャリーサービス ── 旧サイトから何をどう引き継いだか

サイトリニューアルで一番怖いのは、見た目が新しくなった代わりに、検索順位や問い合わせ導線が静かに壊れることです。 今回は宮崎の運送会社「ドーズキャリーサービス」様のリニューアル案件を題材に、デザインより先に何を固めたかを整理します。

サイトリニューアルというと、まずデザイン案やトップページの見た目から話が始まることが多いです。 ですが、旧サイトに一定の検索流入や被リンクがある場合、デザインより先に決めておかないと後戻りしにくいことがあります。それが URL 設計と、旧サイトの情報をどう引き継ぐかという部分です。

この記事は、宮崎で単身引越し・長距離配送・冷蔵冷凍配送などを手がける運送会社「ドーズキャリーサービス」様のサイトリニューアルを題材に、実際にどういう手順で進めたかをまとめたものです。簡潔な概要は ドーズキャリーサービスの構成を整理した事例 にありますが、この記事ではその中身をもう少し詳しく掘り下げます。

なお、この記事にはアクセス数や問い合わせ数の変化といった効果測定の数値は出てきません。今回整理できたのは「何を、どういう手順で実施したか」という事実のみで、効果の数値は本記事の情報源には含まれていないためです。

この記事から持ち帰れるものは、自社のリニューアルにそのまま流用できる手順テンプレートです。具体的には、URL棚卸し表と対応表の列構成(2章)、301リダイレクトの実装方法と設定例(3章)、コンテンツ保持チェックリストの作り方(4章)、公開前後の検証コマンドと確認項目(8章)の4つです。「うちのサイトでも同じことをやるなら、何を作って、何を確認すればよいのか」という観点で読んでいただくのが、この記事の想定です。

1. 案件の概要 ── Before / After

まず全体像です。

主要な固定ページ(トップ、サービス一覧、引越し、冷蔵冷凍配送、即日配送、施設入居引越し、料金、会社情報、FAQ、お問い合わせ)と、宮崎・都城・延岡・日南・小林・日向・西都・串間・えびのの9エリアページは、リニューアル後も URL をそのまま維持しています。変わったのは主に、旧ブログの意味のない URL と、使われていなかった残置スクリプトの扱いです。

なお、新サイトのデザインは、デジタル庁が公開しているデザインシステムを土台に構築しています。デザインをゼロから起こす工程を省くことで、その分の工数をこの記事で扱う URL 設計とコンテンツ引き継ぎに充てられました。この進め方の考え方は なぜ小村ソフトはデジタル庁デザインシステムでHPを作るのか にまとめています。

この事例のポイントを一言でまとめると、「見た目を変える前に、URL とコンテンツの棚卸しを済ませてから着手した」ということに尽きます。以降の章で、その手順を順番に説明します。

この記事の知識マップ

この記事は、宮崎の運送会社のサイトリニューアル事例を通じて、デザイン検討より先にURL棚卸し表と対応表を作り、301リダイレクトへ落とし込む進め方を扱います。同一ホスト内でパスだけが変わるものは_redirectsファイルで、ホスト名が変わるものはCloudflareのRedirect Rulesで実装し、いずれも1ホップで完結させてリダイレクトチェーンを防ぎます。あわせて、料金や営業時間などの判断材料が抜け落ちて問い合わせが減る事故を防ぐコンテンツ保持チェックリスト、実際に機能している導線だけへの問い合わせ集約、DNSが失効して被リンク評価を失う前に旧ドメインを整理する必要性を示します。公開前後にはcurl -Iによる実測確認とSearch Consoleでのリダイレクト認識状況の監視を行い、リニューアルの完了を確認します。

flowchart LR
    accTitle: サイトリニューアルの知識マップ
    accDescr: サイトリニューアルにおいてURL棚卸しと対応表を先に固め、301リダイレクトを_redirectsファイルとCloudflareのRedirect Rulesで実装し、コンテンツ保持チェックリスト・問い合わせ導線の集約・旧ドメインの整理・公開前後の実測検証で補強する関係を示す図
    site_renewal["サイトリニューアル"]
    redirect_301["301リダイレクト"]
    url_inventory["URL棚卸し表"]
    url_mapping_table["URL対応表(リダイレクトマッピング)"]
    redirects_file["_redirectsファイル"]
    cloudflare_redirect_rules["Cloudflare Redirect Rules"]
    cloudflare_pages["Cloudflare Pages"]
    redirect_chain["リダイレクトチェーン"]
    meta_refresh_redirect["meta refreshによる転送"]
    content_retention_checklist["コンテンツ保持チェックリスト"]
    inquiry_drop_risk["問い合わせ減少事故"]
    contact_channel_consolidation["問い合わせ導線の集約"]
    domain_portfolio_cleanup["旧ドメインの整理"]
    backlink_value_loss["被リンク評価・指名検索流入の喪失"]
    dns_expiry["DNSの失効"]
    local_seo_area_page["地域名対応エリアページ"]
    pre_launch_verification["公開前検証"]
    curl_head_check["curl -Iによる実測確認"]
    search_console["Google Search Console"]
    url_inventory -.->|"推奨される対応"| site_renewal
    url_inventory -->|"より先に行うべき"| url_mapping_table
    redirect_301 -->|"実装を担う"| url_mapping_table
    redirects_file -->|"実装を担う"| redirect_301
    cloudflare_redirect_rules -->|"実装を担う"| redirect_301
    cloudflare_pages -->|"利用する"| redirects_file
    redirect_301 -.->|"防止する"| redirect_chain
    meta_refresh_redirect -->|"用いるのは非推奨"| redirect_301
    content_retention_checklist -->|"推奨される対応"| site_renewal
    content_retention_checklist -->|"軽減する"| inquiry_drop_risk
    site_renewal -.->|"原因になり得る"| inquiry_drop_risk
    contact_channel_consolidation -->|"推奨される対応"| site_renewal
    domain_portfolio_cleanup -->|"推奨される対応"| site_renewal
    domain_portfolio_cleanup -->|"防止する"| backlink_value_loss
    dns_expiry -->|"両立しない"| redirect_301
    dns_expiry -.->|"原因になり得る"| backlink_value_loss
    local_seo_area_page -->|"推奨される対応"| site_renewal
    pre_launch_verification -->|"推奨される対応"| site_renewal
    pre_launch_verification -->|"利用する"| curl_head_check
    pre_launch_verification -->|"利用する"| content_retention_checklist
    redirect_301 -->|"で確認できる"| curl_head_check
    redirect_301 -->|"で確認できる"| search_console

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 最初にやったのはデザインではなくURL棚卸し

リニューアル着手時に最初に作ったのは、デザインのラフ案ではなく、旧サイトの全 URL を一覧化した棚卸し表でした。

具体的には、次の単位で漏れなく洗い出しています。

• 固定ページ(トップ、サービス一覧、引越し、冷蔵冷凍配送、即日配送、施設入居引越し、会社情報、プライバシーポリシー、FAQ、料金、ブログ、お問い合わせ)
• エリアページ9枚(宮崎・都城・延岡・日南・小林・日向・西都・串間・えびの)
• 旧ブログの個別記事(エリア密着のコラムから、単身引越しや長距離引越しのノウハウ記事まで100本超)
• robots.txt や sitemap.xml、Search Console の所有権確認用ファイル、旧フォーム送信スクリプト(php/submit.php)などの「ページではないが公開されているファイル」

棚卸し表の列構成は、次の形で足ります。真似する場合はこの列から始めてください。

この棚卸し表ができて初めて、「新サイトでこの URL はどうするか」を1本ずつ判定する対応表(URL マッピング)を作れます。対応表の列は3列で十分です。旧URL・判定・対応先だけを持ち、判定の理由は棚卸し表側の備考に置いておくと、対応表を実装(リダイレクト定義)へ機械的に変換できます。

今回の対応表では、判定を大きく2種類に分けました。

固定ページとエリアページ、そして現行の意味のあるブログ記事URLは、すべて keep(変更なし)です。一方で、システムが自動採番した意味のないランダム文字列の URL(/blog/5lmln1lx0x/ のようなもの)や、post20210721.html のような日付ファイル名の URL は、意味のある slug を持つ新しい記事 URL へ301リダイレクトする設計にしました。

もう一つ、旧サイトに残っていた php/submit.php という送信先スクリプトも判定の対象でした。これは公開されている HTML 一式のどのフォームからも参照されておらず、実際に機能していた問い合わせ導線は電話・メール・LINE見積もりの3系統だけだと確認できたため、「残置された送信先スクリプト」と判断し、/contact/ へ301する扱いにしています(この判断の経緯は6章で詳しく触れます)。

リダイレクトの設計では、次の2点をルールとして徹底しました。

• 1ホップで完結させる(リダイレクトの連鎖=チェーンを作らない)
• ビルド時に宛先URLが実在するかを検証する仕組みを入れる(存在しないURLへ301してしまう事故を防ぐ)

デザインを検討するより前にこの棚卸しと対応表を固めておくと、後工程の実装やコンテンツ作成が「どの URL に何を置くか」という土台の上で進められるので、手戻りが減ります。これはこの案件に限らず、被リンクや検索流入がある旧サイトをリニューアルする際の基本手順として、他の案件にもそのまま当てはまる考え方です。

3. 301リダイレクトをどう実装したか

対応表ができても、それを実際の301レスポンスに変換しなければ意味がありません。ここが最も「記事では省略されがちだが、真似するときに一番困る」部分なので、具体的に書きます。

新サイトは静的サイト生成 + Cloudflare Pages の構成です。この構成では、リダイレクトを出す場所が2か所に分かれます。

この分担を最初に理解していないと、「_redirects に www の行を書いたのに効かない」という時間の使い方をします。_redirects はサイト内のパスに対して働くもので、どのホスト名で来たリクエストかによる振り分けはできません。

3.1 同一ホスト内のパス ── _redirects ファイル

Cloudflare Pages には、ビルド成果物のルートに _redirects という名前のテキストファイルを置くと、その内容に従ってリダイレクトを返す仕組みがあります。1行に「元のパス」「転送先」「ステータスコード」を空白区切りで書くだけの形式です。

/blog/5lmln1lx0x/          /blog/oneroom-mansion-hikkoshi/   301
/blog/post20210721.html    /blog/oneroom-mansion-hikkoshi/   301
/php/submit.php            /contact/                         301

ここで必ず末尾に 301 を明示してください。ステータスコードを省略すると302(一時的な移動)として扱われ、検索評価の引き継ぎを意図した恒久的な移転になりません。静的リダイレクトの上限は2,000件で、それを超える規模になる場合は Bulk Redirects に寄せる必要があります。

今回はこの _redirects を手書きせず、ビルドスクリプトが対応表から生成する構成にしました。ビルド用のスクリプトにリダイレクトの定義を配列として持たせ、出力時に1行ずつ書き出しています。イメージとしては次のような形です。

// 対応表(旧URL → 新URL)を1か所にまとめて持つ
const redirects = [
  ["/blog/5lmln1lx0x/", "/blog/oneroom-mansion-hikkoshi/"],
  ["/blog/post20210721.html", "/blog/oneroom-mansion-hikkoshi/"],
  ["/php/submit.php", "/contact/"],
];

// dist/_redirects に「元のパス 転送先 301」の形式で書き出す
const body = redirects.map(([from, to]) => `${from} ${to} 301`).join("\n");
await fs.writeFile("dist/_redirects", `${body}\n`);

こうしておく利点は2つあります。1つは、2章で決めた「1ホップで完結させる」「宛先URLが実在するか検証する」というルールを、ビルド時の自動テストとして担保できること。今回は、生成された _redirects の中身が期待どおりの本数・内容になっているかを検証するテストを用意し、すべて1ホップの301であることを確認しています。もう1つは、記事のURLを変えたときに対応表の側を直せば _redirects が自動で追従するため、片方だけ直して壊すという事故が起きないことです。

3.2 ホスト名が変わるもの ── Cloudflare の Redirect Rules

www.douzucarry.com から apex(douzucarry.com)への301のように、ホスト名が変わるリダイレクトは Cloudflare ダッシュボード側で設定します。手順は次のとおりです。

1. 対象ゾーンで、www の DNS レコードが存在し、プロキシが有効(Proxied)になっていることを確認する。DNSレコードがないと、そもそもリクエストが Cloudflare に届きません。
2. Rules > Redirect Rules > Create rule を開く。
3. 条件(When)に「Hostname equals www.douzucarry.com」を指定する。
4. 動作(Then)に Dynamic redirect を選び、転送先の式を concat("https://douzucarry.com", http.request.uri.path) とする。ステータスは301、Preserve query string はON。

パスをそのまま引き継ぐ式にしているのは、www 側の各ページを apex の同じパスへ1対1で送るためです。一方、7章で扱う旧LPドメインのように中身が新サイトの1ページに統合されている場合は、逆にパスを引き継いではいけません。ワイルドカードでキャプチャした部分を転送先に付け足すと、/refrigerated/foo のような存在しないURLへ301してしまい、404が増えて評価の集約が崩れます。この場合は転送先を固定URL1点にします。

3.3 どちらでもない選択肢を避ける理由

旧サイトが PHP や Apache で動いていた場合、.htaccess に RewriteRule ... [R=301,L] を書く方法もあります。旧環境をしばらく残す前提ならこれが現実的です。一方で、HTMLの <meta http-equiv="refresh"> による転送は、HTTPのステータスコードとしては200のままなので、301として扱ってほしい場面では選ばないでください。JavaScriptでの location.href 書き換えも同様です。「引っ越しました」を検索エンジンに伝えるには、サーバー側が301を返す必要があります。

4. コンテンツを「落とさない」ための保持チェックリスト

URL の設計と並行して行ったのが、旧サイトに書かれていた情報を新サイトでも欠かさず出せているかを確認するための、コンテンツ保持チェックリストの作成です。

リニューアルでは、デザインを新しくする過程で、細かい訴求文言や数字がいつの間にか抜け落ちることがあります。特に料金、営業時間、連絡先、強みといった「問い合わせ判断に直結する情報」が抜けると、見た目は良くなったのに問い合わせが減るという事故につながりかねません。

そこで、主要ページごとに旧サイトの必須情報を書き出しました。一部を挙げると、次のような内容です。

このチェックリストを作った上で、新サイト公開前に新旧のページを1つずつ照合し、要素が欠けていないかを確認しました。デザインが変わっても、料金や営業時間、強みといった「判断材料」がそのまま引き継がれていることを、勘や記憶に頼らずリストで担保したという点がポイントです。

5. ローカルSEO ── エリアページ9枚の設計

旧サイトから引き継いだページの中には、宮崎・都城・延岡・日南・小林・日向・西都・串間・えびのという、9つのエリアごとの個別ページがあります。

これらのエリアページは、「地名+引越し」「地名+配送」といった、地域名を含む検索クエリの受け皿として用意されているページです。運送・引越しのように商圏が地域に紐づくサービスでは、トップページや料金ページだけでは拾いきれない、地名を含む検索ニーズに対応する役割を持ちます。

URL 対応表を見ると、/area/miyazaki/ から /area/ebino/ までの9枚はすべて keep(URL変更なし)と判定されており、リニューアルでこの構成自体は変えていません。あわせて、各エリアに紐づく形で、地域の具体的な地名(たとえば宮崎市内の各地区や都城市内の各地区など)を扱ったブログ記事も多数あり、エリアページとブログ記事が補完し合う構成になっています。

エリアページのような「同じフォーマットを地名だけ変えて量産する」タイプのページは、内容が薄いと検索エンジンにも読み手にも「同じページの使い回し」に見えてしまうリスクがあります。今回のケースでは、エリアページ本体に加えて、エリア内の地区単位の詳細をブログ記事側で個別に書き分けるという役割分担を旧サイトから引き継ぐ形にしており、量産ページ特有の「薄さ」を避ける構成が既にできていました。リニューアルではこの構成を壊さず、URL もそのまま維持しています。

6. 散らばっていた問い合わせ導線の集約

2章で触れた php/submit.php の扱いは、問い合わせ導線を整理する上でも重要な判断でした。

旧サイトを調べた結果、公開されている問い合わせ導線として実際に機能していたのは、次の3系統だけだと確認できました。

• 電話(0120-931-677、受付時間8:00〜20:00)
• メール
• LINE見積もり

一方で php/submit.php という送信先スクリプト自体はコード上に残っていたものの、公開されている HTML のどのフォームからも参照されていませんでした。つまり、実際には使われていない「残置スクリプト」だったということです。これを踏まえて、新サイトでは電話・メール・LINE見積もりの3系統を /contact/ ページに集約し、php/submit.php へのアクセスは /contact/ へ301する設計にしています。

問い合わせ導線が複数のページやスクリプトに分散していると、どこが実際に使われているのか、リニューアルのタイミングで見えなくなりがちです。今回のように「実際に機能している導線はどれか」を先に洗い出してから集約する進め方は、トップページ・サービスページ・問い合わせページの導線を見直す一般論としても当てはまります。この考え方は、以前書いた 問い合わせが来ないサイトで、先に直すべき3つの場所 でも扱っていますので、あわせて参考にしてください。

7. 旧ドメインの整理 ── 放置されたLPドメインの扱い

運送会社のようにサービスごとにランディングページを別途作ってきた会社では、いつの間にかドメインが複数に分散していることがあります。今回のケースでも、次のようなドメインの整理が必要でした。

3つ目だけが未対応で残っているという状態です。この違いは、次の8章で扱う公開前検証の結果として確認したもので、「設定したつもり」ではなく実際に301が返ることを確かめています。

特に3つ目のケースは、教訓として重要です。旧・冷蔵冷凍配送LPの内容(−20℃対応の冷凍機搭載車、24時間365日対応、定期便・ルート配送といった訴求)は新サイトの /refrigerated/ に移植済みですが、旧ドメイン自体がDNS失効の疑いで名前解決できなくなっているため、旧ドメインからの301リダイレクトを設定できません。ドメインを維持・更新せずに放置すると、そのドメインに蓄積されていた被リンク評価や指名検索の流入を、ある日突然失ってしまう可能性があるということです。

サービスLPを別ドメインで運用している会社がリニューアルを検討する際は、コンテンツの統合先を決めるだけでなく、旧ドメインの契約状況(更新が続いているか、DNSが生きているか)も同時に確認しておくことをおすすめします。復旧できるうちに301を設定できるかどうかで、その後の評価の引き継ぎやすさが変わってきます。

8. 公開前検証と公開後にやること

新サイトを公開する前には、次のような確認を行いました。

• 4章で作ったコンテンツ保持チェックリストとの照合(新旧ページの要素が揃っているか)
• 301リダイレクトの実測確認(実際にリクエストを送り、想定通りのステータスコードと転送先が返るか)
• Search Console の所有権確認用ファイルが、正しく200を返すこと
• robots.txt・sitemap.xml・_headers といった公開に必要なファイルが、実際に公開されていること(_headers は Cloudflare Pages 固有のファイルで、_redirects と同じくビルド成果物のルートに置くと、レスポンスヘッダーをパスごとに追加できます。セキュリティ関連のヘッダーやキャッシュ制御をここでまとめて指定します)

301の実測確認は、ブラウザではなくコマンドで行ってください。ブラウザはリダイレクトを自動で追ってしまうため、途中で302が挟まっていても最終的なページが表示されてしまい、気づけません。curl -I(ヘッダーのみ取得。リダイレクトを追わない)なら、返ってきたステータスコードと Location ヘッダーをそのまま確認できます。

# 旧ブログのID付きURLが、新しいslugのURLへ301になっているか
curl -I https://douzucarry.com/blog/5lmln1lx0x/

# 日付ファイル名の .html URL も同様に確認する
curl -I https://douzucarry.com/blog/post20210721.html

# www で来たリクエストが apex へ301になっているか(パスが引き継がれるかも見る)
curl -I https://www.douzucarry.com/price/

見るべきは1行目のステータス行が 301 であることと、Location: の値が対応表の「対応先」と一致していることの2点です。ここで 302 が返っていれば _redirects のステータスコード書き忘れ、Location の先がさらに別のURLへ転送されていればチェーンができている、という切り分けができます。対応表の redirect 行はすべてこの方法で1本ずつ確認します。

公開後についても、やるべきことがあります。

• sitemap.xml を Search Console に再送信する
• URL検査ツールで、旧ブログのID付きURLや日付ファイル名の.htmlURLが、想定通り301になっているか個別に確認する
• カバレッジレポートで、以前は404やインデックス外だった旧URLが「リダイレクト」として認識されるようになるかを、数週間かけて確認する

リニューアル作業は「公開したら終わり」ではなく、公開後にリダイレクトが検索エンジン側にきちんと認識されるまでをモニタリングして初めて完了する、という前提で計画しておくと安心です。

9. まとめ ── リニューアルで失敗しないための一般則

今回のドーズキャリーサービス様の事例から、他のリニューアル案件にも共通して当てはまる考え方を整理すると、次のようになります。

• URL設計が先、デザインは後。 既存の検索流入や被リンクがある旧サイトでは、見た目を検討する前に、全URLの棚卸しと新URLへの対応表(301マッピング)を確定させる。
• 旧コンテンツの棚卸しなしに公開しない。 料金・営業時間・連絡先・強みといった「判断材料」は、新旧ページを1つずつ照合するチェックリストで確認してから公開する。
• 実際に使われている導線だけを残す。 使われていないフォームや送信先スクリプトを見つけたら、実態を確認した上で、生きている導線へ集約する。
• リダイレクトは1ホップ、宛先の実在確認をセットにする。 チェーンを作らず、存在しないURLへ飛ばさない仕組みを持っておく。
• 301を出す場所は2か所に分かれる。 同一ホスト内のパスはビルド成果物の設定ファイル(Cloudflare Pages なら _redirects)、ホスト名が変わるものはCDN・DNS側のルールで設定する。どちらもステータスコードを明示し、公開前に curl -I で1本ずつ実測する。
• ドメインは生きているうちに整理する。 サービスLP用の別ドメインを放置すると、DNS失効で復旧不能になり、評価を引き継ぐ機会自体を失う。

サイトリニューアルは、単にデザインを新しくする作業ではなく、これまで積み上げてきた検索評価や問い合わせ導線をどう引き継ぐかという設計作業でもあります。この事例の簡潔な概要は ドーズキャリーサービスの構成を整理した事例 にまとめていますので、あわせてご覧ください。

同じようにURL設計や既存コンテンツの引き継ぎに不安がある場合は、ホームページ制作 のご相談の中で、旧サイトの棚卸しから一緒に進められます。

関連記事

• ドーズキャリーサービスの構成を整理した事例
• なぜ小村ソフトはデジタル庁デザインシステムでHPを作るのか ── 安さと品質は両立できる
• 問い合わせが来ないサイトで、先に直すべき3つの場所
• ホームページ制作
• お問い合わせ

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

サイトリニューアルは何から始めるべきですか？

デザイン案ではなく、旧サイトの全URLを一覧化した棚卸し表から始めます。固定ページ、エリアページ、ブログ記事に加え、robots.txtやSearch Consoleの所有権確認用ファイル、フォーム送信スクリプトのような「ページではないが公開されているファイル」まで漏れなく洗い出します。その上で、URLごとにkeep(変更しない)かredirect(301リダイレクト)かを判定する対応表を作ります。この土台を先に固めると、後工程の実装やコンテンツ作成の手戻りが減ります。

リニューアルで検索順位を落とさないためのリダイレクト設計のポイントは？

固定ページやエリアページなど意味のあるURLはそのまま維持(keep)し、システムが自動採番した意味のないURLだけを、意味のあるslugを持つ新URLへ301リダイレクトします。設計ルールとして、リダイレクトは1ホップで完結させてチェーンを作らないこと、ビルド時に宛先URLが実在するかを検証する仕組みを入れて存在しないURLへ301してしまう事故を防ぐこと、の2点を徹底します。公開後はSearch Consoleでリダイレクトが認識されるまで数週間モニタリングします。

リニューアルで問い合わせが減る事故はなぜ起きますか？

デザインを新しくする過程で、料金・営業時間・連絡先・強みといった問い合わせ判断に直結する情報がいつの間にか抜け落ちることがあるためです。対策として、主要ページごとに旧サイトの必須情報(料金プラン、受付時間、対応サービスなど)を書き出したコンテンツ保持チェックリストを作り、公開前に新旧のページを1つずつ照合します。勘や記憶に頼らずリストで担保することがポイントです。

使っていない別ドメインのLPは放置しても問題ありませんか？

放置は危険です。この事例では、冷蔵冷凍配送の旧LP用ドメインがDNS失効の疑いで名前解決できなくなっており、コンテンツは新サイトへ移植済みでも、旧ドメインからの301リダイレクトを設定できない状態になっていました。ドメインを維持・更新せずに放置すると、蓄積されていた被リンク評価や指名検索の流入をある日突然失う可能性があります。リニューアル検討時には、旧ドメインの契約状況とDNSが生きているかを同時に確認し、復旧できるうちに301を設定すべきです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。