リダイレクトマップのレシピ：保持するリンクで旧URLをランク付けする
リダイレクトマップは、すべてのURLをリストしたスプレッドシートではなく、優先順位リストです。他のサイトからリンクされているページから始めましょう。残りのマップ作成も容易になります。
ArchiLinksリサーチチーム ·
リンクでランク付けする理由
チームはクロールデータからマップを作成します。それは完全ですが、2014年に忘れられたプレスページをホームページと同じ重みで扱ってしまうという欠点があります。
サイトのバックリンクを確認し、リンク元ドメイン数でページをソートすると、ほとんどの移行で共通するパターンが見えてきます。数十のURLが外部からの価値の大部分を保持しています。これらのURLは手動でマッチングされ、2回レビューされ、最初にテストされます。
その他のURLはルールに従います。フォルダはパターンでマッピングし、パラメータは削除し、リンクもトラフィックもない孤立URLは、判断次第で410ステータスを返すことができます。移行チェックリストと組み合わせて、マップを公開前にテストし、45日目に再確認してください。また、APIスクリプトを使用して、月次プルをスケジュールしてください。
ステップ1：リンクされたページを取得する
1回の呼び出しで最大1,000行が返され、行数に関係なく2クレジットかかります。以下のフィールド名は例です。実際のレスポンスを確認し、キーを調整してください。
import csv, requests
BASE = "https://archilinks.com/api.php"
KEY = "sk_live_..."
def call(action, **params):
r = requests.get(BASE, params={"action": action, "key": KEY, **params}, timeout=30)
r.raise_for_status()
return r.json()
data = call("toppages", q="old-shop.com", per=1000)
rows = next(v for v in data.values() if isinstance(v, list))
with open("linked-pages.csv", "w", newline="") as f:
w = csv.writer(f)
w.writerow(["old_url", "links", "new_url"])
for row in rows:
w.writerow([row.get("url"), row.get("backlinks"), ""])ステップ2：3列目を埋める
意味でマッチさせる
商品ページは同じ商品ページへ、または商品が販売終了の場合はそのカテゴリページへリダイレクトします。ページが元々ホームページだった場合を除き、ホームページへはリダイレクトしないでください。
2人目の担当者にトップ50を確認させる
午後6時に疲れた担当者は、canonicalに関するガイドをブログインデックスにマッピングしてしまうことがあります。レビューアーがそれを検出します。
ロングテールのためのルール
フォルダのパターンを記述し、トラッキングパラメータを削除してください。各ルールは、なぜそのルールにしたのかというコメント付きでバージョン管理に保持してください。
ステップ3：サーバールールを出力する
nginxはマップファイルを高速に処理でき、数万行のスケーラビリティがあります。
# /etc/nginx/redirects.map (generated from the csv)
/old/guide-canonicals /guides/canonical-tags;
/products/blue-widget /shop/widgets/blue;
# in nginx.conf, http context
map $request_uri $new_uri {
default "";
include /etc/nginx/redirects.map;
}
# in the server block of the old host
if ($new_uri) {
return 301 https://new-shop.com$new_uri;
}
ステップ4：各ホップをテストする
単一の301リダイレクトで200ステータスに到達しない場合は、パイプラインを失敗させます。
while IFS=, read -r old new; do
out=$(curl -s -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}" -L "https://old-shop.com$old")
echo "$old -> $out"
done < redirect-pairs.csv | grep -v "^.* -> 200 1 " && echo "FIX ABOVE"最初に確認すべきミス
| 症状 | 考えられる原因 | 修正方法 |
|---|---|---|
| 2〜3ホップのチェーン | 古いルールが新しいルールの上に積み重なっている | 古いルールを最終URLへ直接ポイントする |
| すべてがホームページにリダイレクトされる | 簡易なcatch-allルール | トピックでマッチさせる。Googleは大量のホームページリダイレクトをソフト404として扱う可能性があります。 |
| クエリ文字列が失われる | ルールが引数をドロップしている | コンテンツを変更するパラメータを引き継ぎ、それ以外は削除する |
| トップURLが公開後に404を返す | CSVから漏れた | プルを再実行し、ライブマップとの差分を確認する |
どのURLが手動マッチの行を獲得するか
すべてのURLが人手による対応を必要とするわけではありません。有用な基準はリンク元ドメイン数です。複数の外部サイトからリンクされているURLは手動でマッチングし、残りはルールセットに従います。例えば、4,000件の旧URLがあり、その60件が外部リンクの大部分を保持している場合。その60件には午後のレビュー時間を費やし、残りの3,940件にはパターンとテストを適用します。
閾値を人の頭の中ではなくスクリプト内に保持してください。リンク元ドメイン数が5という基準は、中規模サイトには適しています。そこから始めてください。サイト全体のリンクが少ない場合は数値を下げ、手動リストがレビューアーにとって長すぎる場合は数値を上げてください。
手動マッチ行とルールマッチ行を分けて保持する
手動マッチ行には、レビュー担当者名とターゲットが選ばれた理由のメモが含まれます。ルールマッチ行には、フォルダ全体に対してテストされるパターンが含まれるため、例外が公開後のトラフィックチャートではなく、公開前のテストレポートで検出されます。
混合ケースが混乱の大部分を引き起こします。販売終了し、後継製品に置き換えられた製品は後継製品へマッピングします。後継製品のない販売終了製品はカテゴリに属し、ホームページには属しません。
2回目のプルで変更内容を確認する
マップが最終化される前に旧ホストでrefdomainsを実行し、公開後に再度実行します。ドメインごとに2つのリストをマッチさせます。2回目のプルでリンク元ドメインが欠落している場合、それはリンクオーナーへの質問事項であり、警戒すべき理由ではありません。リンクが削除されてからインデックスに反映されるまでには時間がかかるためです。
両方のファイルを移行フォルダに日付付きの名前で並べて保存してください。diffは調査すべき場所を、マップはそれに対して何を行ったかを示します。
リンクのないURLの処理方針の決定
リンクもトラフィックもない孤立URLは最も簡単な部分です。コンテンツが完全に削除された場合は明確な404または410を返し、近しい代替が存在する場合のみリダイレクトしてください。これにより、訪問者もクローラーも有用な場所に到達できます。
確信が持てない場合は、マップに短いメモを残し、最初の1週間のログを確認してから再度検討してください。サーバーログは、どの旧アドレスにまだリクエストが届いているかを示しており、これは最も確かな証拠となります。
マップがリリースにどう組み込まれるか
リダイレクトマップはサイトの変化に伴って変更されます。これを念頭に置いてください。新しいページが追加され、古いページが改名され、テンプレートの変更が先月までは安全だったルールを破綻させることがあります。マップをコードとして扱い、バージョン管理で1つのファイルとして管理し、各デプロイ前にレビューを行い、変更ごとにテスト実行を行ってください。
可能であればマップを1つのレイヤーに保持してください。アプリケーション、CDN、CMSにまたがるリダイレクトはチェーンの発生原因となり、チェーンは完全なクロールなしでは発見が困難です。
ルールはどこに配置すべきか
サーバーマップは高速でテストが容易です。CMSプラグインは数ページには便利ですが、大規模な監査は困難です。どちらを選ぶにせよ、1ホップテストはその同じ場所から読み取る必要があります。
2つのレイヤーが同じURLをリダイレクトする場合、テストはチェーンとして報告します。廃止予定のレイヤーから重複を削除してください。
変更ごとに本番環境でテストする
ルールファイルへの変更ごとに、ステージング環境でホップテストを実行し、その後本番環境で実行してください。ステージング環境で合格したルールでも、キャッシュが古いレスポンスを保持している場合、本番環境では失敗することがあります。2回目の実行が重要です。
日付付きで出力を保存してください。トップURLが数ヶ月後に破綻した場合、古い結果はルールが変更されたのか、サイト自体が変更されたのかを示します。移行チェックリストには、そのテストがいつ行われるべきかが記載されており、最初に実行することで、次のチェックが今回の結果と比較可能になります。
ルールファイルへの変更をレビューする
マップへの変更には1人のレビュー担当者を指名し、その人物に以下の3点を確認させてください：各ターゲットが依然として対象と一致しているか、ルールが生成するホップ数、パターンが書かれたURLのみに影響するほど十分に狭い範囲か。レビューされていない変更は、チェーンを引き起こす可能性が最も高いものです。
サイト自体が変更される際も同じレビューを依頼してください。古いフォルダを吸収する新しいカテゴリが作成されると、マップが編集されなくても、正しいルールが間違った場所を指すことがあります。
レビューアのメモを変更の隣に保存してください。6ヶ月後、そのメモはそれまで不自然に見えたルールの理由を説明し、同じ質問に対する2回目の調査を節約します。
全実行前にサンプルをテストする
全リストを実行する前に、トップリンクページと通常ページを混ぜた50行のサンプルを選択してください。まずそのサンプルでホップテストを実行してください。サンプルは読み取りが速く、ルールエラーは全ファイル全体に現れるずっと前に検出されます。
各ルールパターンから少なくとも1行、各手動マッチグループから少なくとも1行を含めてください。200URLのフォルダをカバーするパターンは、サンプルに含まれる行によってのみテストされるため、意図的に選択してください。
ルールファイルを小さく保つ
数百パターンを超えるルールファイルはレビューが困難になります。サイトのセクションごとに分割し、各ファイルを1回のセッションで読める長さに保ってください。
フォルダが削除されたら、その日のルールを削除してください。残された古いルールは、後にトラフィックをチェーンに送り込む原因となります。
マップ公開前
- 各行には新しいURL、または意図的な404または410が含まれている。
- ターゲット自体がリダイレクトではない。
- リンク元ドメイン数が最も多い50URLは2人目の人物によってレビュー済み。
- コンテンツを変更するクエリパラメータは引き継がれている。
- ルールファイルはバージョン管理下にあり、各パターンにコメントが付いている。
- 公開後の差分用に参照ドメインのベースラインが保存されている。
頻出するリダイレクトの質問
- 1年後に古いリダイレクトを削除すべきか？
- 多くの移行チームは少なくとも1年間保持します。それ以降は、旧URLに外部リンクやトラフィックが残っている限り保持してください。リダイレクトの提供コストはほぼゼロなので、早期に削除する良い理由はほとんどありません。
- インデックス登録されているページのみをリダイレクトしても問題ないか？
- インデックス未登録のページにリンクがある場合は問題です。インデックスステータスは外部価値についてほとんど示しません。リンク元ドメインを持つすべてのURLをリダイレクトし、残りはトラフィックに基づいて判断してください。
- 恒久的な移動に302または307は問題ないか？
- 恒久的な移動には301または308を使用してください。302を長期間放置すると恒久的なものとして扱われる可能性がありますが、その結果は偶然に委ねられ、リダイレクトの他のクライアントが同じように推測するとは限りません。
- 旧サイトの404を新サイトにリダイレクトできるか？
- 近しい一致が存在する場合のみ可能です。無関係なページへのリダイレクトはGoogleにとってソフト404と見なされます。コンテンツが完全に削除された場合は、実際の404または410を返してください。
