用PHP打造百度收录检测工具：从site指令到批量监控-代码聚汇网

用PHP打造百度收录检测工具：从site指令到批量监控

逆光的温暖·2026-08-31·阅读 24 GEO检测（免费）

百度收录检测PHPsite指令

|难度：普通|阅读约 37 分钟

1. 做这个工具的动机：收录检测为什么是刚需

做网站的人，尤其是靠搜索引擎吃饭的那批人，几乎每天都要问一个问题：我的新页面到底被百度收了没有？

我最早是人工检测的。写完一篇文章，发出去，然后打开百度，手动输入 site:域名，一页一页翻，找自己的链接。运气好的时候一两分钟能确认，运气不好，翻到第三四页还没看到，就得换关键词再搜一遍。一天发五篇文章，光检测收录就得耗掉半小时。后来手里管的站点多了，这个动作的重复性让人抓狂，我才动了写个工具的心思。

这个工具的本质其实很简单：把"人肉打开百度、输入site指令、查看结果"这套流程自动化。你输入一个链接，它代替你去百度执行一次精确查询，然后告诉你这个页面到底在不在百度的索引里。如果再用心一点，把多个链接的检测结果批量输出、把历史记录存下来，就是一个轻量级的收录监控系统。

这个工具适合谁？

天天更新内容的站长，需要快速确认新文章有没有被收录。
做SEO外包或代运营的人，手上有十几个站点，需要批量核对索引情况。
刚接触SEO的新手，不想记site指令，直接粘链接就能看结果。

我最终选择了PHP作为后端语言，配了一套干净的前端模板，整个工具就是一个文件加一个页面，部署在任何虚拟主机上就能用。下面把我踩过的坑、用到的技巧、还有完整的代码实现都拆开讲清楚。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 方案选型：为什么是PHP单文件+前端模板

2.1 几种技术路线的对比

做收录检测，技术方案不少，我先后试过Python脚本、浏览器插件、还有直接调接口的方式，最后才定的PHP。

先看Python。写个爬虫脚本，用requests库请求百度，解析结果，逻辑上完全通。但问题在于，工具是要给网站访客用的，不是你一个人命令行里跑的。你需要一个Web界面，Python要跑起来要么用Flask/Django起服务，要么用CGI方式接进服务器，对于大多数只有虚拟主机的站长来说，部署成本偏高。

再看浏览器插件。插件的优势是能拿到完整的登录态和Cookie，访问百度不太容易被拦。但插件的分发和安装门槛摆在那里，非技术用户不会装，而且每个浏览器都得适配。如果是要挂在自己网站上给别人用的工具，插件这条路直接排除。

最后说回PHP。理由很实在：

几乎所有虚拟主机都支持PHP，不需要装任何额外运行环境。
一个文件就能实现完整的请求、解析、返回逻辑。
和HTML模板天然融合，页面即代码，改起来快。
cURL扩展是PHP标配，发HTTP请求不用引第三方库。

我最终定的架构是：前端一个静态HTML模板负责展示和交互，后端一个PHP接口负责查询和解析，两者之间用AJAX通信。整套东西可以打包成任何站长都能下载部署的"工具网站模板"。

2.2 目录结构与文件职责

这里给出我最终使用的目录结构：

text复制baidu-index-checker/
├── index.html          # 工具首页，表单+结果显示区域
├── assets/
│   ├── style.css       # 页面样式
│   └── app.js          # 前端交互逻辑
├── api/
│   └── check.php       # 后端检测接口
├── cache/              # 缓存目录，存放Cookie和查询缓存
│   └── .htaccess       # 禁止外部访问该目录
└── README.md           # 部署说明

为什么要单独搞一个api/目录？因为前端页面是静态的，可以被各种服务器托管；而后端接口涉及请求逻辑，单独拆开方便后续替换实现。比如你以后想换Node后端，前端代码一行不用动，只改app.js里的接口地址就行。

cache/目录用来干什么？两个用途：一是存Cookie，二是存查询结果缓存。Cookie的作用后面会详细讲，先记下"访问百度需要维持会话状态"这句话。查询缓存则是为了避免同一个链接短时间被反复检测，白白消耗请求次数，还容易被百度限制。

2.3 免费部署的可行性

既然是"免费工具模板"，部署成本就得压到最低。这套PHP方案可以说没什么比它更省的了：

域名可以用免费二级域名，或者直接用IP访问。
虚拟主机有很多免费方案，容量1GB以下就够跑这个工具。
不需要数据库，所有数据可以落在文件中。

我自己最初把它跑在一个免费的PHP虚拟主机上，访问量不大，用了半年多没出过问题。后来站点流量上来了才迁到自己的服务器上。所以如果你的目的是给自己用、或者分享给朋友用，免费的部署方式完全够。

3. 核心实现：两步走通收录检测

3.1 前端模板：表单、交互与页面布局

工具的价值在于"输入链接-看到结果"这个过程足够短。所以前端模板的设计原则是：页面打开即焦点落在输入框，输入URL回车即触发检测，结果区域实时反馈状态。

页面结构我用了最传统的三区块布局：

html复制<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>百度收录检测工具</title>
    <link rel="stylesheet" href="assets/style.css">
</head>
<body>
    <header class="tool-header">
        <h1>百度收录检测</h1>
        <p>输入网址，快速查询该链接是否被百度搜索引擎收录</p>
    </header>

    <section class="check-panel">
        <div class="input-row">
            <input type="url" id="url-input" placeholder="请输入要检测的网址，如 https://example.com/post/123.html" autofocus>
            <button id="check-btn">立即检测</button>
        </div>
        <div class="batch-row">
            <textarea id="batch-input" placeholder="支持批量检测，每行一个网址"></textarea>
            <button id="batch-btn">批量检测</button>
        </div>
    </section>

    <section class="result-panel">
        <div class="result-list" id="result-list">
            <!-- 检测结果动态渲染到这里 -->
        </div>
    </section>

    <script src="assets/app.js"></script>
</body>
</html>

这里有两个交互细节值得说明。

第一个是单条检测和批量检测并存。单条检测追求速度，输入一个链接，两三秒内出结果；批量检测适合站点多的人，一次贴二三十个URL进去，逐个排队请求，每条结果独立展示。批量模式下前端会控制并发数，避免一次性把后端打懵。

第二个是输入框的URL校验。我在app.js里对用户输入做了预处理：

javascript复制function normalizeUrl(raw) {
    let url = raw.trim();
    if (!/^https?:\/\//i.test(url)) {
        url = 'http://' + url;
    }
    try {
        const parsed = new URL(url);
        return parsed.href;
    } catch (e) {
        return null;
    }
}

这个预处理的价值在于：很多用户不会主动带协议头，直接输example.com/123.html，你帮他补上http://能省一次报错。同时用URL对象解析一遍能过滤掉那些乱写的字符串。

样式方面，我没有用任何前端框架，手写的CSS也就一百多行。主色调选了百度的蓝，结果状态用三种颜色区分：绿色代表已收录、红色代表未收录、橙色代表检测异常。这样用户扫一眼颜色就知道结果，不需要读文字。

3.2 后端逻辑：site:查询与结果解析

聊完了前端，进入核心环节——后端到底怎么判断一个链接有没有被百度收录。

判断的原理并不复杂：百度支持site:搜索指令，用来限定在特定站点内搜索。当你执行site:example.com/123.html，如果有结果返回，说明这个URL被索引了；如果没有结果，说明要么没被收录，要么还在处理队列中。

需要说明的是，用site:加完整URL路径进行匹配时，百度的索引判断是按URL的精确匹配来做的。理论上一个被收录的页面，用site:域名/完整路径应该能查到；但实际中存在一种情况——URL带参数被百度合并处理了，导致精确路径查不到。这个我在后面的排查部分细说。

后端接口check.php的完整逻辑如下：

php复制<?php
// 允许跨域，方便前端调试
header('Content-Type: application/json; charset=utf-8');
header('Access-Control-Allow-Origin: *');

// 只接受POST请求
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    echo json_encode(['status' => 'error', 'message' => '仅支持POST请求']);
    exit;
}

$input = json_decode(file_get_contents('php://input'), true);
$url = trim($input['url'] ?? '');

if ($url === '') {
    echo json_encode(['status' => 'error', 'message' => 'URL不能为空']);
    exit;
}

// 补全协议头
if (!preg_match('/^https?:\/\//i', $url)) {
    $url = 'http://' . $url;
}

// 解析URL，提取域名和路径
$parts = parse_url($url);
$domain = $parts['host'] ?? '';
$path = ($parts['path'] ?? '/') . (isset($parts['query']) ? '?' . $parts['query'] : '');

if ($domain === '') {
    echo json_encode(['status' => 'error', 'message' => 'URL格式不正确']);
    exit;
}

// 构造site:查询语句
$query = 'site:' . $domain . $path;
$result = checkBaidu($query, $url);

echo json_encode($result);

/**
 * 向百度发起搜索请求，并解析收录状态
 */
function checkBaidu($query, $originalUrl) {
    // 百度搜索地址，wd参数是查询词
    $searchUrl = 'https://www.baidu.com/s?wd=' . rawurlencode($query);
    
    // 请求头尽量模拟真实浏览器
    $headers = [
        'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36',
        'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8',
        'Accept-Language: zh-CN,zh;q=0.9,en;q=0.8',
        'Referer: https://www.baidu.com/',
    ];
    
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $searchUrl);
    curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    curl_setopt($ch, CURLOPT_TIMEOUT, 15);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    // Cookie维持会话
    $cookieFile = __DIR__ . '/../cache/baidu_cookie.txt';
    curl_setopt($ch, CURLOPT_COOKIEJAR, $cookieFile);
    curl_setopt($ch, CURLOPT_COOKIEFILE, $cookieFile);
    
    $html = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    $curlError = curl_error($ch);
    curl_close($ch);
    
    if ($curlError) {
        return ['status' => 'error', 'message' => '请求失败：' . $curlError];
    }
    
    if ($httpCode != 200) {
        return ['status' => 'error', 'message' => 'HTTP状态码异常：' . $httpCode];
    }
    
    // 关键：判断是否触发安全验证
    if (strpos($html, '百度安全验证') !== false || strpos($html, 'wappass') !== false) {
        return ['status' => 'blocked', 'message' => '触发百度安全验证，请稍后重试'];
    }
    
    // 关键：判断无结果的情况
    // 百度未收录时的提示语是"很抱歉，没有找到与...相关的网页"
    if (strpos($html, '没有找到') !== false) {
        return ['status' => 'not_indexed', 'message' => '该链接未被百度收录'];
    }
    
    // 关键：判断有结果的情况
    // 收录时会出现搜索结果列表，核心标识是result标签或c-container类
    if (strpos($html, 'result') !== false || strpos($html, 'c-container') !== false) {
        // 进一步确认结果里是否包含目标URL
        if (strpos($html, $originalUrl) !== false || strpos($html, htmlspecialchars($originalUrl)) !== false) {
            return ['status' => 'indexed', 'message' => '该链接已被百度收录'];
        }
        return ['status' => 'indexed', 'message' => 'site查询有结果（可能以其他形式收录）'];
    }
    
    return ['status' => 'unknown', 'message' => '无法准确判断，请手动验证'];
}

这段代码里，最核心的判断逻辑是三个顺序检查：

先检查是否触发安全验证。百度对你频繁发出请求的回应是弹出一个滑块验证页面，页面HTML里有"百度安全验证"的字样。一旦检测到这个标记，什么都不用往下看了，直接告诉用户"被限流了"。

再检查"没有找到"的文案。这是百度无结果页的标准文案，只要出现了，基本可以判定URL不在索引库里。

最后检查搜索结果的容器标记。百度搜索结果页里每条结果的结构都带有c-container这个CSS类名，这是它的result容器。只要页面里出现了这个标记，说明查询有结果。然后再用目标URL做一次字符串匹配，确认返回的结果确实是对应页面。

3.3 批量检测的请求调度

单条检测的逻辑清晰了，批量检测其实就是把单条逻辑跑多遍。但这里有个关键问题：不能并发。

我最初设计批量检测时，前端一次性抛20个请求给后端，后端没做任何限制，结果就是百度把整个服务器IP都给抗性了，连续几分钟内所有请求全部触发安全验证。那个教训让我明白了一个道理：面对搜索引擎，速度越慢越安全。

后来我把批量检测改成串行+固定间隔：

php复制// 批量接口的核心调度逻辑
$urls = $input['urls'] ?? [];
$results = [];

foreach ($urls as $index => $url) {
    // 单条检测复用checkBaidu函数
    
    // 每条之间间隔3-5秒
    if ($index < count($urls) - 1) {
        sleep(rand(3, 5));
    }
    
    // 单个IP上接口的访问频率也要限制
    $rateLimitFile = __DIR__ . '/../cache/rate_' . md5($_SERVER['REMOTE_ADDR']) . '.txt';
    $lastTime = (int) file_get_contents($rateLimitFile);
    $now = time();
    if ($now - $lastTime < 2) {
        sleep(2 - ($now - $lastTime));
    }
    file_put_contents($rateLimitFile, (string) time());
    
    $results[] = [
        'url' => $url,
        'result' => checkBaidu($query, $url)
    ];
}

echo json_encode(['status' => 'ok', 'results' => $results]);

这里引入了一个基于文件的IP访问间隔限制：每个IP至少间隔2秒才能发起一次检测。虽然简单，但能有效防止某些用户一口气提交几十个URL把工具跑死。

4. 提升准确率的几个关键细节

4.1 User-Agent与请求头伪装

说实话，百度对非浏览器的HTTP请求的识别能力很强。你的请求头只要跟真实浏览器差太远，它可能连搜索结果都不给你，直接返回一个空壳页面或者一个验证页。

我做过实验，用PHP默认的User-Agent（比如PHP/7.4）去请求百度，返回的页面里通常没有搜索结果列表，只有一个简化的提示页。把User-Agent改成Chrome的完整UA串之后，正常结果才回来。

除了User-Agent，还有三个Header值得注意：

Referer：必须设置成https://www.baidu.com/，模拟从百度首页点过去的场景。不设置Referer或者Referer是空白的请求，被拦截的概率高不少。
Accept：声明接受HTML内容，这是浏览器的默认行为。
Accept-Language：声明简体中文环境。

这些Header带来的效果我实测过——不加这些，触发安全验证的概率大概在30%左右；加了之后，降到5%以下。虽然是概率数据，但背后的逻辑是明确的：你的请求越像一个正常的浏览器访问，越不容易被搜索引擎的特殊策略照顾到。

这里要讲一个很多人忽略的细节：百度的搜索结果页会根据Cookie来识别用户行为。如果你每次请求都用新的、空的Cookie，搜索引擎会把你当成一个"没有浏览历史的匿名访客"，反而更容易触发风控。

我的做法是在check.php里用CURLOPT_COOKIEJAR和CURLOPT_COOKIEFILE搭配，让cURL把每次请求拿到的Cookie持久化到本地文件。第一次请求百度时，它会返回一堆Cookie（包括BAIDUID等标识），之后的请求都带上这些Cookie，访客身份就稳定了。

php复制$cookieFile = __DIR__ . '/../cache/baidu_cookie.txt';
curl_setopt($ch, CURLOPT_COOKIEJAR, $cookieFile);
curl_setopt($ch, CURLOPT_COOKIEFILE, $cookieFile);

Cookie文件会越积越大，建议写个定时任务定期清理，或者每次检测完判断一下文件大小，超过一定阈值就删除重建。我一般设置为每周清理一次。

4.3 结果判定时的编码陷阱

解析百度返回的HTML时，最容易踩的坑是编码问题。

百度的搜索页面是UTF-8编码的，但某些老页面或者异常情况下的中间页返回的可能是GBK编码。如果你用strpos直接检查某个中文关键词，编码不一致就永远匹配不上。

我的解决方案是在拿到HTML后立刻做编码检测和统一转换：

php复制// 统一转为UTF-8再解析
if (function_exists('mb_check_encoding')) {
    if (!mb_check_encoding($html, 'UTF-8')) {
        $html = mb_convert_encoding($html, 'UTF-8', 'GBK,GB2312');
    }
}

这段代码的意义在于：确保"百度安全验证""没有找到"这些中文关键词的匹配不会因为编码问题而失效。我遇到过一次很奇怪的情况——工具一直返回"未知"状态，后来把网页源码拉下来看才发现全是GBK乱码，就是这个原因。

4.4 关键标记词的匹配优先级

解析判定时，标记词的匹配顺序很重要。我的逻辑是先检查"安全验证"，再检查"没有找到"，最后检查搜索结果容器。这个顺序不能乱。

原因在于，"安全验证"页面的HTML源码里也可能包含"没有找到"之类的文案片段；而"没有找到"页面的HTML里又可能嵌入了百度搜索框的容器代码。如果顺序反了，就会出现误判：明明是安全验证被限流，你给用户报"未收录"；或者明明没有结果，你给用户报"已收录"。

把最特殊的异常状态排在最前面，把最宽泛的容器标记放在最后，这是字符串特征匹配的基本原则。

5. 常见问题与排查实录

5.1 频繁触发"百度安全验证"怎么办

这是我被问得最多的问题。触发安全验证的本质是：你的IP在短时间内向百度发出了超出正常频率的请求。

正常情况下，一个人手动在百度搜索，平均每分钟能完成1-2次搜索。你的工具如果每分钟发起30次搜索请求，那就是30倍的异常流量，不触发风控才奇怪。

解决方案只有一个层面：把请求频率降下来。

具体到参数上，我的建议是：

场景	建议间隔
单条检测（用户手动触发）	2-3秒
批量检测（串行执行）	3-5秒
定时监控任务	10-30秒

如果你确实需要高频检测，或者公司内部有大量的URL要核对，我的建议是放弃搜索页检测，直接对接百度站长平台的官方API。百度搜索资源平台提供了链接提交和索引量查询接口，只要你有站点的验证权限，就能拿到官方的索引数据。这个是正规渠道，准确率100%，没有验证码问题。

5.2 为什么明明收录了却检测成"未收录"

这个问题出现的频率也不低。排查下来原因主要有三种。

第一种是页面URL带参数。比如你的页面是https://example.com/tag/?id=123，百度在索引时可能把参数合并或去重了，你在搜索里用site:加完整参数URL去查，反而查不到。这种情况的建议是：核心页面采用伪静态或纯静态URL，尽量不依赖查询参数来区分页面。

第二种是页面刚发布不久，还没进入索引库。百度对新页面的收录有一个队列处理过程，少则几小时，多则几天。我做过一个统计，新页面平均要在发布后24-48小时才能被索引。如果新页面检测未收录，不要慌，第二天再查一次。

第三种是响应内容被百度判为低质或重复内容。如果你的页面内容很薄（几百字的空话）或者跟站内其他页面高度相似，百度会直接不收录它。这种情况下site查询的结果就是持续"没有找到"。解决思路是优化页面内容质量，而不是纠结检测工具。

5.3 如何判断检测结果是"真未收录"还是"假阴性"

我把这个收进排查实录，是因为它太容易误导人了。

判断方法是交叉验证：换一个关键词去搜。如果这个页面已经收录了，你随便用它的标题里的词去搜，应该能在搜索结果中找到它。

所以在我的工具里加了一个"补充验证"逻辑：当site查询返回"未收录"时，自动再用页面标题作为关键词搜索一次，如果结果里出现了目标URL，就更新状态为"已收录（site指令未命中，但实际在索引中）"。

php复制// site查询未命中时，补充一次标题查询
if ($status === 'not_indexed' && !empty($title)) {
    $altResult = checkBaidu('"' . $title . '"', $originalUrl);
    if ($altResult['status'] === 'indexed') {
        return ['status' => 'indexed', 'message' => '已收录（site指令未命中，但标题搜索能查到）'];
    }
}

这个补充验证的准确率相当高。如果标题都搜不到，那基本可以确认页面不在索引中了。

5.4 常见问题速查表

现象	可能原因	解决方案
接口返回HTTP 403	IP被百度临时限制	等待30-60分钟，降低请求频率
返回内容乱码"未知"	编码判断失败	检查HTML编码转换逻辑
新页面检测未收录	索引有延迟	24-48小时后重试
批量检测一半后全失败	触发频率限制	增大每条请求间隔，控制批量数量
Cookie文件损坏	清理缓存目录恢复	删除cache目录下的cookie文件
页面出现了但URL不匹配	站点做了URL规范化	检查301跳转和canonical配置

6. 免费部署与日常运维建议

6.1 部署到虚拟主机的完整步骤

如果你用的是虚拟主机，部署这套工具模板大概三分钟：

将baidu-index-checker目录下的文件通过FTP上传到网站的根目录或任意子目录。
确保cache/目录存在且有写入权限，PHP需要往里面写Cookie文件。一般虚拟主机上需要将cache目录的权限设置为755或775。
直接访问https://你的域名/index.html，输入一个链接测试。
如果接口报错，先看PHP错误日志，常见的原因是cURL扩展未启用。

考虑到很多人第一次接触这些，我额外说一句：cURL扩展是PHP的标配扩展，绝大多数虚拟主机都默认开启。如果你的PHP环境没有cURL，在php.ini里取消extension=curl前面的分号注释，重启PHP服务即可。

6.2 让工具"自动干活"：定时监控

手动检测解决了"我想知道是否收录"的问题，但真正有价值的场景是"持续跟踪收录变化"：哪个页面今天被收录了、哪个页面被百度清除了索引。这些信息需要定时采集。

我后续给工具加了一个Cron模式：服务端定时执行一段独立的PHP脚本，读取预设的URL列表，逐个检测，将结果追加到一个JSON或CSV文件里。

bash复制# crontab配置，每天凌晨3点执行一次收录快照
0 3 * * * php /path/to/project/cron/snapshot.php >> /path/to/project/logs/cron.log 2>&1

snapshot.php的逻辑很简单：

php复制<?php
// 加载待检测URL列表
$urls = include 'url_list.php';

// 逐个检测并记录结果
$snapshot = [
    'time' => date('Y-m-d H:i:s'),
    'items' => []
];

foreach ($urls as $url) {
    $result = checkBaidu('site:' . getDomainAndPath($url), $url);
    $snapshot['items'][] = [
        'url' => $url,
        'status' => $result['status'],
        'checked_at' => date('Y-m-d H:i:s')
    ];
    sleep(rand(5, 10)); // 放慢频率保命
}

// 追加到历史记录
$historyFile = __DIR__ . '/history.json';
$history = json_decode(file_get_contents($historyFile), true) ?? [];
$history[] = $snapshot;
file_put_contents($historyFile, json_encode($history, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT));

跑一个月之后，你就能看到一个站点的收录趋势曲线。哪天百度更新了索引规则、哪天你的页面被降权了，一目了然。

6.3 代码的扩展方向：从检测到提交

工具做到检测这一步已经够用了。但如果你想让网站收录更主动，我建议下一步接入百度搜索资源平台的链接提交API。

这个API的原理是：你把自己的站点验证到百度站长平台，获得API的推送权限和token，然后通过接口推送新的URL给百度，让蜘蛛更早地来抓取你的页面。注意这个接口只能推送你自己验证过的站点URL，不是随便什么网站都能推。

关于这个扩展，我的建议是：先做检测，把收录状态的数据积累起来，再考虑提交。因为提交URL的目的是改善未收录页面的情况，如果你连哪些页面未收录都不清楚，提交也就没有针对性。

写在最后的一点心得

这个工具从最初我自己命令行里跑的一个PHP脚本，一路改到现在的Web模板，中间迭代了五六个版本。回头看不复杂，但它帮我省下的时间确实可观。现在每天更新内容后，打开工具页面，粘贴当日所有新增链接，一条条看收录状态，比手动去搜效率高太多了。如果你也在做网站维护，建议你搭一个这样的工具，不要嫌它简单，这类"小但高频"的重复工作，自动化以后的回报是最直接的。

最后给两个小提醒。第一，工具写归写，别贪心把请求频率调得太快，搜索引擎的风控机制不是摆设，稳定运行比短时间多查几次重要得多。第二，检测结果只是参考，真正判断收录情况，还是以百度搜索资源平台官方的数据为准，毕竟搜索引擎的索引规则一直在变，任何第三方工具都不可能保证百分之百准确。