キャンペーン、SEO、アフィリエイト向け Broken Link Monitoring と Failover

リンク自体が正常に見えても、その先のdestinationが壊れていることがあります。ブランドURLは開ける。QR codeも読み取れる。広告、メール、LINE配信、affiliateの管理画面にもdestinationは残っている。けれど一つか二つ先のhopで、LPが非公開になっていたり、商品URLが消えていたり、partner URLが変わっていたり、移行先ページが404を返していたりします。

だからbroken link monitoringは「slugが存在するか」だけでは足りません。訪問者と同じ経路をたどり、final destinationを確認し、重要なparameterを残し、alert、pause、route to fallback、human reviewのどれを行うかを決める必要があります。

この記事は、公開後のリンクを運用するgrowth、SEO、EC、affiliate、platform team向けです。

運用原則

source URLではなく、destination outcomeを監視します。

実務で必要な確認は5つです。

1. source URLは解決できるか
2. final destinationまでにどのredirect hopsがあるか
3. final destinationは期待するstatusとcontent typeを返すか
4. UTM、affiliate ID、locale path、device fallbackは保たれるか
5. destinationが不健康な場合、alert、pause、route to fallback、human reviewのどれを行うか

最後の判断が重要です。自動failoverは常に正解ではありません。広告LPなら承認済みbackupへすぐ切り替えてよい場合があります。一方、SEO移行先では、正当な404や410を雑に隠さないよう、人の確認が先になることがあります。

brokenまたはriskと見るべき状態

監視対象はHTTP 404だけではありません。ページが技術的に読み込めても、流入に対しては壊れていることがあります。

これは単なるcrawlではなくlink operationsです。URLがonlineかどうかではなく、訪問者の経路とattribution contractを守ることが目的です。

まず監視すべきリンク

すべてのリンクを同じ頻度で見る必要はありません。失敗時のコストが明確なものから始めます。

各グループで期待結果を決めておきます。status 200だけでは不足です。商品、store、language、campaign sourceが違えば、そのリンクは運用上壊れています。

alert前にtriage policyを作る

alertは、次に何をするか決まっていて初めて役に立ちます。

高価値リンクには4つの項目を持たせます。

広告では、承認済みfallbackがあればLP修正中も予算を守れます。SEO移行先では慎重さが必要です。欠落ページはreplacement page、410、redirect map修正のどれかであり、常にhomepageへ送るべきではありません。

failoverはhomepage redirectではない

すべてのbroken destinationをhomepageへ送ると、問題は隠れますが、ユーザーには悪い答えになりやすいです。campaignやmigrationのreportも読みにくくなります。

fallbackは元の意図に近いものを選びます。

自動failoverは、fallbackが事前承認され、元の意図に近い場合に向いています。承認済みfallbackがないなら、alertやpauseのほうが安全です。

parameterとattributionを守る

status checkをすべて通っても、reportingが壊れることがあります。

launch前に保持すべきparameterを決めます。

• utm_source、utm_medium、utm_campaign、utm_content、utm_term
• affiliate ID、partner sub ID
• coupon、creator code、channel code
• country、language、store parameter
• mobile fallback用app campaign parameter
• server-side analytics用internal rule ID

fallback時も意味のあるparameterは保持します。paid socialのclickがbackup categoryへ行く場合でも、campaign contextは残すべきです。affiliate linkでpartner IDを落とすなら明示的な判断が必要です。

UrlEdgeはdestination monitoringを UTM Builder、Temporary 302 Redirects、rule-level analyticsと組み合わせられます。failoverがtrafficを守ったのか、別の場所へ問題を移しただけなのかを確認できます。

SEO、campaign、affiliateでpolicyを分ける

誤った対応は、broken linkそのものより悪くなることがあります。

SEO migration targets

移行URLのfailureは、automatic routing前にreviewを挟むことが多いです。404は誤削除かもしれませんが、本当にreplacementがない場合もあります。Bulk URL Management、Redirect Checker、redirect chains and loops を確認します。

paid/lifecycle campaigns

広告、email、SMS、QR、socialではdowntimeが直接コストになります。fallbackが事前承認済みなら、ownerがLPを直す間もcampaignを維持できます。未承認ならpauseまたはalertにします。

affiliate/partner links

affiliate destinationはstatusだけでなくparameterを見ます。partner pageが200でもaffiliate IDが消えればcommission reportingは壊れます。final destination、redirect chain、parameter preservation、timeoutを監視します。

app fallback links

device-aware linkはiOS、Android、desktopで期待値を分けます。iOSが正常でもAndroidが死んだページなら、リンクは部分的に壊れています。storeとweb fallbackがplatformごとに違う場合は Device Targeting を使います。

UrlEdgeでの位置づけ

UrlEdgeは、broken link対応をtraffic pathの近くで行いたい場合に向いています。

実務フローは次の通りです。

1. Consoleでbranded linkまたはredirect ruleを作る
2. expected final destination、status、parameter policy、owner、fallbackを定義する
3. Redirect Checker で経路を検証する
4. Broken Link Monitor でdestination healthを監視する
5. policyが許す場合、承認済みtemporary fallbackへtrafficをrouteする
6. bot、proxy、suspicious trafficをdestination前で止めたい場合は Link Firewall を使う
7. domain、rule、status、country、device、destination別analyticsを見てから恒久対応にする

目的はすべてのerrorを隠すことではありません。destinationのdriftを早く知り、守るべきtrafficを守り、page、redirect、partner routeを直す証拠を残すことです。

よくある失敗

launch前だけ確認する

launch QAはsetup errorを見つけます。monitoringはlaunch後のdriftを見つけます。LP非公開、campaign終了、affiliate URL変更、商品削除、origin遅延、新しいredirect chainなどです。

すべての404を緊急扱いする

削除済みresourceは404または410でよい場合があります。問題は、まだactive trafficを受けるlinkが予期せず404になることです。

ownerなしでfailoverする

fallbackを誰も承認していない場合、自動routingは第二の問題を作ります。重要リンクにはownerとresponse policyが必要です。

soft failuresを無視する

timeout、loop、wrong-country page、UTM消失、affiliate ID消失は、hard 404と同じくらい損失を出します。checkに含めます。

FAQ

failoverは常に自動にすべきですか？

いいえ。fallbackが事前承認され、元の意図に近いときに向いています。SEO target、sensitive page、partner linkはhuman reviewが必要なことが多いです。

どれくらいの頻度でcheckしますか？

business riskで決めます。active paid campaign、印刷済みQR、app fallback link、高価値migration targetは、archive linkより高頻度にします。

404は常に悪いですか？

いいえ。削除済みresourceは404または410でよい場合があります。問題は、active trafficを持つlinkが予期せず404になることです。

fallbackで何を保持すべきですか？

訪問の理解とattributionに必要な情報です。UTM、affiliate ID、campaign ID、locale、device context、reporting contractのinternal rule IDを保持します。

参考資料

• MDN: 404 Not Found
• MDN: Redirections in HTTP
• Google Search Central: HTTP status codes and network errors