robots.txt 和 meta robots 仅是向合规爬虫声明意愿的辅助协议，不具备访问控制能力；真正防爬必须依赖服务端身份校验、限流、行为识别等机制。
robots.txt 只是礼貌协议，不是访问控制开关
robots.txt 文件根本不能阻止爬虫抓取——它只是告诉遵守规则的爬虫“请勿访问这些路径”。恶意爬虫（比如数据采集脚本、暴力扫描器）压根不读这个文件，直接请求 /admin.php 或 /api/user 照样能拿到内容。
常见错误现象：把敏感接口地址写进 Disallow: /api/ 就以为安全了；上线后发现日志里大量非搜索引擎 UA 正在高频调用这些接口。
- robots.txt 是公开可读的，等于主动暴露目录结构和敏感路径
- 不支持通配符匹配（
*）、正则或条件判断，只认前缀匹配 - 无法按 User-Agent 做细粒度放行/拦截（比如只允许 Googlebot 访问某路径）
- 部分爬虫会故意伪造
User-Agent: Googlebot绕过规则
meta name="robots" 对已抓取页面无效
<meta name="robots" content="noindex, nofollow"> 仅影响搜索引擎是否将当前页面加入索引、是否跟踪链接，**完全不影响页面是否被下载**。只要 URL 被知道，爬虫仍可 GET 到 HTML 源码并提取其中任意文本、URL、隐藏字段。
使用场景有限：适合临时下线但不想 404 的页面（如活动页结束），或含重复内容的分页页（避免 SEO 权重稀释）。
立即学习“前端免费学习笔记（深入）”；
- 对静态资源（JS/CSS/图片）无任何约束力
- 对 AJAX 渲染的内容不起作用（搜索引擎可能根本没执行 JS）
- 如果页面已被收录，加了
noindex后需等待下次抓取+处理，期间仍可见 - 服务端渲染（SSR）页面中，该 meta 标签必须由服务端注入，前端 JS 动态插入无效
真正防爬要靠服务端逻辑，不是 HTML 标签
HTML 层面没有任何机制能阻止 HTTP 请求到达你的服务器。防爬核心在服务端：验证身份、限流、识别行为模式、混淆关键字段。
例如用户列表页返回 JSON 数据，不要依赖前端 JS 拼接 /api/users?page=2 并设 meta noindex，而应在服务端做：
- 强制登录态校验（
Authorizationheader 或 session cookie） - 对
/api/users接口启用 IP + 用户级 QPS 限制（如 5次/分钟） - 响应中关键字段（如
user_id）用短期有效 token 加密，而非明文 ID - 对高频、低停留、无 referer 的请求返回 403 或混淆数据（不是 404）
前端埋点、按钮禁用、JS 混淆都只是增加采集成本，不能替代服务端防护。
robots.txt 和 meta 的合理定位：辅助性声明
它们唯一可靠的作用，是向合规爬虫（Google、Bing、百度等）表达你的内容分发意愿，属于 SEO 协作范畴，不是安全边界。
容易被忽略的细节：
- robots.txt 必须放在域名根路径（
https://example.com/robots.txt），子目录无效 - meta robots 在 HTML
<head>中才生效，放在<body>会被忽略 - 多个 meta robots 标签会合并效果，但冲突时以最后一个为准（不推荐写多个）
- 搜索引擎对
noarchive、nosnippet等扩展指令支持不一，别默认全平台生效
想靠 HTML 阻止爬取，就像用门牌号拒绝快递上门——地址写了，门没锁，人照样进来。
