使用 Google 搜索 API 查找公司网站

TL;DR:

• 公司网站发现产生候选人，而不是经过验证的匹配。 包含公司名称的结果并不能确定网站所有权。
• 使用实体上下文搜索。 保留公司标识符、名称、市场和业务描述，以便审查员能够区分相似的组织。
• 记录匹配背后的证据。 在公司到网站表中保留候选网址、实体检查、不确定性和最终审查员决定。

公司列表通常包含没有可靠网站URL的名称。一些名称由无关的企业共享；另一些名称指的是子公司、以前的品牌或位置。选择第一个搜索结果可能会将这种模糊性转化为看似自信的错误，这种错误在数据集中传播。

Scrapeless Google Search API 提供公司网站发现的结构化搜索结果。这里的工作流程使用这些结果来构建候选队列和审核映射。它并不声称提供完整的公司数据库、联系信息或经过验证的电子邮件地址。

确定您需要哪家公司和哪种网站

从输入数据集中开始使用一个稳定的公司标识符。名称在搜索中是有用的，但不应作为映射的主键。两个记录可以共享一个名称，并仍然代表不同的实体。

保持组织名称完全按接收的方式，并在单独的字段中添加已知上下文：运营市场、行业、位置、母公司或产品名称。保留该上下文的来源。未经验证的增强不应悄然成为用来验证下一个字段的证据。

决定所需的URL代表什么。企业主页、区域网站、品牌网站和子公司网站是不同的目的地。有效的子页面不应仅仅因为一个未说明的规则期望父公司的根域名而被拒绝。

在研究之前定义可接受的结果：确认匹配、需要审核的合理候选人、未解决的模糊性，以及在收集样本中没有经过验证的匹配。当原因可见时，没有确认匹配的记录依然是有用的。

从已知上下文构建查询

使用公司名称和少量相关上下文。行业或地理位置可以帮助区分共享名称。将每个确切查询和公司标识符保持在一起，以便审查员知道搜索旨在找到哪个实体。

不要添加想象的事实使查询看起来更加具体。一个猜测的城市可能会将搜索引导到错误的组织，然后看似确认了这个猜测。如果输入记录缺乏上下文，请标记模糊性，并在您的工作流程中请求更好的源数据。

Google Search参数提供国家、语言和位置控制。故意配置它们，并保留完整的请求。国家上下文并不能证明公司注册或所有权；它描述了您要求观察的搜索。

在解决具体不确定性时，使用第二个独立证明的查询，例如确定公司是否使用以前的名称。单独保留观察结果。查询变化是研究活动，而不是重写原始输入记录的理由。

收集候选人及其原始证据

Google Search请求工作流程使用 scraper.google.search 和 POST https://api.scrapeless.com/api/v1/scraper/request 以及 x-api-token 头。设置应在 input 内。实时收集需要您的账户密钥和实际响应的检查；该工作流程并不声称进行经过身份验证的运行。

存储完整的请求、原始响应、客户端观察时间和公司标识符。HTTP 200表示任务数据；HTTP 201表示待处理任务。不要仅因为收集待处理或失败而将公司标记为没有网站。

对于自然搜索结果，保留返回的标题、URL、摘要和位置（如存在）。在原始记录中保留缺失或空字段，而不是用虚构文本替换它们。JSON 数据模型支持这种区分。

在分配所有权之前创建候选行。目录列表、新闻文章或名称相似的公司可能是有用的证据，但并不是所需的首页。将候选人的明显角色与是否匹配分开标记。

群组主机名而不声称所有权

使用 URL 解析器分离方案、主机名、路径和查询。 URL 解析参考 解释了这些组件，并明确表示解析并不是验证网站身份的过程。

避免子字符串所有权规则。包含品牌词的主机名可以归属于无关方。比较显式审核的主机名并保留原始 URL。如果您的组织将选定的子域名归为一组，请记录该政策，而不是假设每个共享后缀都识别同一业务。

根域名计算也需要谨慎。公共后缀各不相同，因此仅提取主机名的最后标签并不能满足一般所有权测试。 公共后缀列表解释 有助于阐明域名边界；但它仍然无法验证域名背后的业务。

将目录和社交资料保留在证据队列中，但将其与公司的官方网站区分开。它们可以在审核后帮助区分一个组织，而不至于默认成为最终主页。

使用 Scrapeless 开始抓取

使用 Scrapeless 提升您的网页抓取和自动化工作流程！
今天注册并获得 5 美元的免费积分 — 无需信用卡。

立即在 Scrapeless Dashboard 领取您的免费积分。

在目标页面验证实体

打开每个有潜力的目标并检查企业身份。比较组织描述、位置、产品和已知输入上下文的母公司关系。如果导航重定向，请保留请求的 URL 和最终目的地。

不要仅靠公司名称做决定。共享名称加上不兼容的行业是一个冲突，即使结果排名显著。匹配名称加上一致的商业上下文是更有力的证据，但要记录检查的内容，而不是将其隐藏在未解释的可信度评分后面。

搜索片段仍然作为发现证据。谷歌描述了 片段是如何生成的；它们可以强调与查询相关的文本。在声称其标识目标公司之前，先审核目的地。

对于一个名为 Harbor Analytics 的假设输入，审核者可能会发现一家软件公司和一家无关的咨询公司。这个例子说明了决策过程，而不是观察到的搜索结果。对于输入上下文不足的正确回应是未解决的匹配，而不是随便猜测的主页。

制作可审核的公司与网站表格

最终表格应使决策可检查。保留公司 ID、输入名称、选定 URL、选定主机名、网站角色、匹配状态、证据引用、审核者和审核时间。一个单独的候选表可以保留所有检查过的 URL 和排除原因。

仅在明确状态的情况下使用空白的选定 URL。“没有验证匹配”可能表示所收集的候选者不足，而“模棱两可”可能表示多个目标符合可用上下文。这两种说法都不能证明该组织没有网站。

保留重定向和历史名称作为观察，带有日期放在您的内部系统中。在后续搜索返回不同的着陆页面时，请勿自动覆盖已确认的映射。相反，创建一个包含旧证据和新证据的审核事件。

如果数据集供 CRM 使用，请将公司级映射附加到正确的组织记录。将任务限于公司网站。个人联系收集和电子邮件验证是单独的工作流程，不是此过程的输出。

在扩展收集之前衡量审核质量

根据相同的书面标准审核已接受和已拒绝的匹配样本。记录审核者之间的分歧及模糊之源。这揭示了问题是否出在查询上下文、网站角色规则或来源数据不足上。

将收集覆盖范围与匹配结果分开。一份报告可以说明哪些计划搜索已完成以及哪些公司获得了审核匹配。不要将所有提交的搜索视为每一个都产生了可用证据。

一个有用的未解决队列记录了下一步所需的信息：法定名称、市场、母公司关系或审核过的目的地。这是数据所有者的实际交接。一个通用的低信心标签通常会让下一个人没有明确的行动。

结论

构建公司网站发现作为一个有证据支持的匹配过程。搜索找到候选目的地；主机名处理对它们进行组织；页面审核确定它们是否适合预期的实体和网站角色。保留不确定性，以便一个干净的表格不会掩盖错误的匹配。

经过审核的公司网站也可以通过区分页面背后的组织来帮助范围 内容差距分析 在比较其内容之前。

构建您的下一个搜索观察

使用 Scrapeless Google搜索API 收集该工作流程的搜索证据。在规划您的收集预算时查看 Scrapeless定价，并将 Google搜索参数 保持在您的请求配置旁边。

在 Discord 或 Telegram 上与社区讨论您的实施。

常见问题

问：第一个自然结果是官方公司网站吗？

不一定。这是一个候选。比较目的地的商业身份与已知的公司背景，然后再接受它。

问：找到一个域名是否验证电子邮件地址？

不。这一工作流程将公司映射到经过审核的网站。它不收集或验证电子邮件地址。

问：目录列表应该被丢弃吗？

在审核后可以作为支持证据保留，但应标记为目录，而非公司的主页。

问：如果几家公司同名该怎么办？

使用可靠的上下文，例如行业、市场或母组织。如果可用证据无法区分它们，则保持匹配未解决。

问：没有经过验证的匹配是否意味着公司没有网站？

不。这描述了该研究样本的结果。收集不完整、上下文不足或候选者未解决都可能导致没有经过验证的匹配。