一括Webサイトチェッカーを使うと、企業URLをまとめて確認し、Website Status、HTTP Status Code、Final URL、Page Title、Error Messageを取得できます。Datablistでは、CSVまたはExcelのリストに対して**Website Status & Parked Domain Checker**を実行し、まずサンプルでテストしたうえで、不確かな結果を調査してからCRMレコードを更新してください。

WebサイトにアクセスできるかどうかはURLに関する判断材料であり、企業が営業中または廃業済みであることの証明ではありません。 正常に表示されるページが、活動を停止した企業のものである可能性もあります。リクエストの失敗も、一時的な障害、古いURL、アクセス制限などが原因かもしれません。

チェック結果と企業ステータスの判断は、別々に管理することをおすすめします。そうすれば、技術的なエラーを理由に誤ってアカウントを削除することなく、チーム用の確認キューを作成できます。

Webサイトチェッカーの機能

このenrichmentは、指定されたWebサイトURLからページを取得し、そのレスポンスを分類します。オプションを無効にしない限り、キャッシュ済みのページコンテンツが再利用される場合があります。

  • Online: ページコンテンツの取得に成功し、Parked判定の条件にも該当しなかった状態です。ただし、企業が実際に営業していることや、メールを配信できることまでは確認できません。
  • Redirected: リクエストが別のドメインに到達した状態です。スキームの変更やパスのみの変更は、企業ドメインの変更とは判定されません。
  • Parked: Page Title、コンテンツ、URLのパターンが、ツールのParked判定ルールに該当した状態です。プレースホルダーやメンテナンス中の文言は、人による確認が必要な場合があるため、実際のページをご確認ください。
  • Unreachable: リクエストエラーまたは正常ではないレスポンスにより、利用可能なページ結果を取得できなかった状態です。ドメインが存在しないと決めつけず、HTTPコードとエラー内容をご確認ください。

企業名しかないリストでは、最初にWebサイトを特定する必要があります。そのようなデータをお持ちの場合は、企業名からWebサイトを探す方法をご覧になり、ドメインの一致状況を確認してからチェックを実行してください。

Webサイトのステータスを確認する手順

ステップ1:データを読み込む

CSVまたはExcelファイルをcollectionにインポートします。Company Name、Original Website、変更されないCRM IDまたはソースIDを保持してください。不確かな一致結果で元のWebサイトが上書きされないよう、チェッカーの出力先には新しいpropertyを指定します。

Datablistのcollectionにファイルを読み込む
Datablistのcollectionにファイルを読み込む

入力例として、アカウント001にhttps://acme.example、アカウント002に以前のドメインが登録されているケースを考えます。サンプルには、通常のURL、既知のリダイレクト、確認が必要なレコードをバランスよく含めてください。これらは入力形式の例であり、実際に動作を確認したWebサイトではありません。

ステップ2:Status Checkerを開く

enrichment catalogを開き、Website Status & Parked Domain Checkerを選択します。この機能は、既存の各rowに登録されたWebサイトURLを処理するものであり、自社サイトを訪れた匿名ユーザーを特定するものではありません。

Website Status and Parked Domain Checker enrichmentを開く
Website Status and Parked Domain Checker enrichmentを開く

「自社のWebサイトを訪問している企業を知りたい」とお考えの場合は、この違いにご注意ください。このワークフローは、ご自身で指定した企業URLをチェックするものです。訪問企業の特定やWebサイト分析を行うプロダクトではありません。

ステップ3:設定を行いWebサイト項目を紐付ける

Website Urlを、企業の元URLが保存されているpropertyに紐付けます。入力が空欄または無効な場合は、有効性を正しく確認できるよう、事前に修正してください。

Proxy Policyでは、Use proxy on error (default)、Always use proxy、No proxyのいずれかを選択します。デフォルトのポリシーでは、取得に失敗した際にproxy経由で再試行できます。ただし、リクエストの成功や、最初のアクセスが拒否された原因の特定を保証するものではありません。

Webサイト項目をenrichmentの入力に紐付ける
Webサイト項目をenrichmentの入力に紐付ける

このenrichmentでは、過去7日以内にキャッシュされたページコンテンツが再利用される場合があります。直近の変更を調査するために最新のページを取得したい場合は、Disable cached dataを有効にしてください。また、collectionには独自のチェック日を記録しましょう。キャッシュを使用したチェックの実行日時と、実際にページを取得した日時は一致しない場合があります。

予算を見積もる際は、enrichment設定画面に表示されるコストと、実行後に報告される使用量をご確認ください。Proxyやキャッシュの利用状況によって使用量が変わる可能性があるため、すべての結果を同一コストの新規リクエストとして計算しないでください。

ステップ4:出力項目を選ぶ

リストを確認する目的であれば、Website Status、HTTP Status Code、Final URL、Page Title、Error Messageの5項目をすべて紐付けてください。それぞれ異なる情報を確認できます。

enrichmentの出力項目を選択する
enrichmentの出力項目を選択する

Website Statusは結果の概要です。Final URLは、ドメイン変更の調査に役立ちます。Page TitleとError Messageからは、Parked判定や取得失敗の理由を確認できます。HTTPコードはそのリクエストに関する情報であり、それだけで企業ステータスを判断できるものではありません。

Keep、Verify domain、Retry、Investigate business statusなど、チームで管理する確認用propertyも別途追加してください。チェッカーがこうしたビジネス上の判断を自動で行うことはありません。

ステップ5:Instant Runを開く

入力と出力を設定したら、Continue with Instant Runを選択します。collectionの残りを処理する前に、少数のレコードでテストしてください。

Instant Runメニューを開く
Instant Runメニューを開く

実際のデータを反映したサンプルを用意しましょう。問題なく表示できる最新のトップページだけでは、古いドメインやアクセス制限のあるサイトがどのように処理されるかを確認できません。

ステップ6:サンプルでテストする

設定した実行範囲を確認し、数rowを処理します。元のURL、Final URL、Page Titleを企業レコードと照合してください。エラーは、成功した結果とは分けて確認します。

サンプルrowでenrichmentを実行する
サンプルrowでenrichmentを実行する

バッチには、アプリケーション上で利用できる適切な実行モードを使用してください。Run in Asyncはジョブの実行方法に関する設定です。Webサイトへのリクエスト失敗が、企業の廃業を示す証拠に変わるわけではありません。

enrichmentの実行状況
enrichmentの実行状況

最新データとの比較が必要な場合は、キャッシュ設定を意図的に変更してください。同じキャッシュ済みリクエストを何度も実行しても、独立した確認結果にはなりません。

ステップ7:結果を確認して全件に実行する

残りのデータを処理する前に、サンプル結果をご確認ください。誤った入力propertyが紐付けられている場合や、無関係な企業へリダイレクトされている場合は、先に設定またはソースデータを修正します。

Webサイトのステータス結果を確認する
Webサイトのステータス結果を確認する

サンプルから有用な結果を得られたら、対象となる残りのrowを処理します。CRMへ戻す際に追跡できるよう、元のソースIDと確認済みの判断結果を保持してください。

残りのrowにenrichmentを実行する
残りのrowにenrichmentを実行する

チェック結果の見方

技術的な出力とビジネス上の結論を分けるため、以下の判断例をご活用ください。

結果確認すべき点避けるべき判断
Online、コンテンツ取得成功意図した企業のページであることを確認できるか。すべての連絡先やメールアドレスが最新だと判断する。
別ドメインへRedirected元の企業、遷移先の企業情報、変更された理由。ドメイン変更を自動的に買収と判断する。
Parked、「近日公開」などのタイトルプレースホルダー、リニューアル準備中、または無関係なドメインのどれに該当するか。企業アカウントをすぐに削除する。
Unreachable、リクエストエラーエラーの詳細、ソースURL、必要に応じた後日の再取得。1回のチェック失敗だけで企業を廃業扱いにする。

リダイレクトを確認する

遷移先の企業名や事業内容を、対象アカウントと比較してください。ドメインのリダイレクトは、リブランディング、買収、ホスティングの変更、または無関係なページへの遷移を示す可能性があります。どのケースに該当するかを確認してからCRMを更新してください。

Webサイトがリダイレクトされるという理由だけで、メールドメインを置き換えないでください。Webとメールのルーティングは別の仕組みです。連絡先メールアドレスを変更する前に、適切なメール検証ワークフローをご利用ください。

Parkedドメインを特定する

この分類機能は、取得したコンテンツ、タイトル、URLに含まれるパターンを使用します。「近日公開」などのプレースホルダーコンテンツを検出できますが、これはサイトを確認する必要があるというサインにすぎません。企業登記情報の照会や、正式な廃業通知の確認を行うものではありません。

結果は確認キューに残し、顧客との関係に関する情報も保持してください。企業が現在も活動しているかどうかを判断するには、別の情報源やアカウント担当者への確認が必要な場合があります。

アクセスできないサイトへの対応

エラー内容とHTTPコードをご確認ください。ページパスの不備、サーバー障害、リクエストのブロックでは、企業情報の変更が確認された場合と意味が異なります。

指定されたURLが現在も正しいか、キャッシュが使用されたかをご確認ください。一時的な問題と考えられる場合は、意図的に再試行します。解決していないレコードは否定的な事実に置き換えず、要確認として残してください。

まとめ

Webサイトチェックを活用して、企業リストにおける作業の優先順位を決めましょう。レスポンスを新たに取得するかキャッシュから確認し、リダイレクトやエラーを調査したうえで、承認済みの判断結果を元のレコードIDとともにエクスポートします。技術的なステータスと企業ステータスは、別々の項目で管理してください。

活用シーン

CRMデータのクレンジング

定期的なチェックにより、Webサイトの確認が必要なアカウントを見つけられます。それらを一括削除せず、確認担当者へ振り分けてください。修正履歴を追跡できるよう、元のURLとアカウントIDを保持します。

見込み顧客リストのクレンジング

enrichmentの前に、不確かなWebサイトの一致結果を確認します。誤ったドメインや古いソースレコードを発見できる場合がありますが、すべてのメールアドレスの有効性や、Outboundに適した相手かどうかを確認できるわけではありません。データクレンジングや、次のワークフローに必要なチェックと組み合わせてください。

リブランディングの検出

Final URLの変更は、調査対象を見つけるためのシグナルになります。メッセージ内でリブランディングや買収に言及する前に、企業の同一性と変更理由をご確認ください。確認済みレコードには、その判断を裏付ける情報も保存します。

FAQ

このツールはWebサイトへアクセスしますか?

ページコンテンツを取得しますが、キャッシュ済みのレスポンスが再利用される場合があります。最新のページを取得する必要がある場合は、Disable cached dataを有効にしてください。

Parkedドメインを検出できますか?

Parkedドメインやプレースホルダーページに関連するパターンを検出します。ヒューリスティックな判定には修正が必要な場合もあるため、実際のページと背景情報をご確認ください。このチェックだけで企業の廃業が確定するわけではありません。

Webサイトがbotをブロックする場合は?

Proxy Policyと表示されたエラーをご確認ください。Proxy経由で再試行するとコンテンツを取得できる場合がありますが、それでも失敗する可能性があります。アクセス制限によって信頼できる確認ができない場合は、未解決の結果として扱ってください。

Onlineなら企業は営業中ですか?

Onlineは、Webサイトチェックのルールに基づき、利用可能なページコンテンツが見つかったことを意味します。CRM上のアカウントステータスを変更したり、レコードを削除したりする前に、適切な根拠から企業の活動状況をご確認ください。