企业官网建设流程全解析

授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。

一、为什么会卡在这一步

1.1 两种听起来都很有道理的极端

想给一个站点写第一个自动抓取脚本的人，几乎都会在同一个地方卡住：“我到底能不能抓？”

围绕这个问题，网上流传着两种截然相反的答案，而且两种都被说得理直气壮。

第一种说：“看 robots.txt 就行了，它写了 Disallow 的地方你就不能碰。”这句话把 robots.txt 当成了一纸法律——仿佛那是一道禁令，违反了就要承担法律责任。

第二种说：“robots.txt 不过是个君子协定，没人真管，随便抓。”这句话又走到了另一个极端——仿佛只要页面没有技术拦阻，就默认获得了许可。

两种说法各自抓住了一小块真相，也都漏掉了最关键的一小块。它们共同的错误其实只有一个：把三个不同层次的东西，硬压成了一层。

1.2 三层边界，得拆开看

真相是：从"我想抓"到"我能抓、我该抓"，中间隔着三层完全不同的边界，而且这三层是由三类完全不同的主体分别定下来的。

这三层不是"同一件事的三种说法"，而是三个彼此独立的关卡。过得了第一层，不代表过了第二层；把前两层都走顺了，也不代表没有触碰第三层。

举个方向性的对照，就能看出它们差在哪：robots.txt 写的是"我请求你别碰这些路径"；网站条款写的是"你使用本站，即表示同意这些条件"；法律写的是"这些行为国家不允许"。三句话的语气不同、来源不同、后果也不同。把它们压成一句"能不能抓"，就必然出错。

本文要做的事只有一件：把这三层逐层拆开，让"我到底站在哪一层"这个问题有明确的答案。

1.3 本文明确不写什么

动笔之前先把边界钉死。本文不是抓取教程，以下内容一个字都不写：

• 不写抓取脚本、不写请求构造；
• 不写反爬绕过、限速规避、代理轮换、并发抓取；
• 不写任何会改变远端状态的请求；
• 不点名任何具体站点或具体爬虫的行为。

全文只做两件事：教你怎么读懂一份 robots.txt，以及帮你把三层边界分清。读懂规则、分清层级，本身就是"动手之前"该做完的功课。

本章可以带走的一句：把"能不能抓"当成一个问题，出发点就已经错了——它其实是三个问题。

二、第一层：robots.txt 到底是什么

2.1 它是一份放在固定位置的文件

先把第一层的事实基础立稳。按照《Robots Exclusion Protocol》这份文档，它的状态是Standards Track（标准轨道），2022 年 9 月发布，RFC 编号9309，作者来自 Google LLC（台账 R01）。它要解决的问题写在摘要里：让服务方控制其服务所提供的内容可以如何、乃至是否可以，被自动客户端——也就是爬虫——访问（台账 R02）。

这份协议在实现上落得很实：规则必须放在一个名为robots.txt的文件里（台账 R05）。也就是说，第一层的入口是一个位置固定、名字固定的文本文件——它固定挂在站点的根路径下，而不是随便放在哪个目录里：

某页面地址: https://<站点>/某个栏目/某个页面 规则文件地址: https://<站点>/robots.txt

上面这个对照只是想说明"位置固定"这件事：无论你想抓的是哪一个页面，规则文件都在同一个根路径上；判断你能不能碰那些页面的那份声明，也只有这一个入口。

这里初学者最容易犯的错，是先入为主地认为"没有 robots.txt"和"robots.txt 里没写我"是一回事。其实不是——这个文件存不存在、写了什么，是两个独立的问题。第四章会专门讲"取不到"的两种情形，它们处理方式完全相反。

2.2 协议语言只有两个构件：rule 与 group

打开一份 robots.txt，你看到的并不是"一堆禁令"，而是一种结构非常简单的语言。按 RFC 9309 的描述，这套协议语言由两个构件组成（台账 R05）：

• rule（规则）：一组键值对，最常见的键就是User-agent、Allow、Disallow；
• group（组）：一组user-agent行，后面跟着若干条规则。

换句话说，robots.txt 不是"一句话"，而是"按组组织的一小段配置"。读它的时候，正确的顺序是先判断这条规则属于哪个 group，再看这条规则说了什么——顺序反了，就会把甲组写给某类爬虫的规则，误当成对所有人的规定。

一条规则长什么样？下面用 RFC 自带的写法示意（这是协议文档里的示例形态，用于说明语言，不是在教你部署）：

User-agent: * Allow: /example/page/ Disallow: /example/page/disallowed.gif

说明一句：这里之所以标成bash围栏，是为了让代码块有明确标注、内容能对齐显示；它本身不是一段可执行脚本，只是用来展示协议语言的形态。

2.3 最后一个 group 可以没有规则，等于隐式允许

这是 R05 里最容易被忽略、但对"读"最关键的一条：

最后一个 group 可以没有规则，这意味着它隐式地允许一切。

也就是说，一个 group 里只写了User-agent:行、后面一条Allow/Disallow都没有，这不表示"禁止"，恰恰表示"允许"：

User-agent: SomeCrawler

上面这个 group 只声明了"这段话是说给SomeCrawler听的"，没有给出任何限制，因此它对该爬虫等于隐式放开全部路径。

这一条之所以重要，是因为它直接推翻了很多人的直觉——看见User-agent就以为在设限制。事实上，限制来自规则本身，不来自User-agent行。User-agent只是"这段话是说给谁听的"。

本章可以带走的一句：robots.txt 是一种"按组组织的语言"，只写User-agent而不写规则，含义反而是允许。

三、第二层之前先学会读一条规则

3.1 匹配从路径的第一个八位组开始

读懂一条规则，关键在"它到底匹配什么"。RFC 9309 把判定规则讲得很细（台账 R06），其中第一句就该记住：

匹配必须从路径的第一个八位组开始。

这句话的专业味道很重，翻译成人话是：规则是拿 URL 的路径部分，从头一个字符一个字符地比，不是"包含"关系。所以一条Disallow: /admin管的并不是"任何地址里含 admin 的页面"，而是"路径从/admin开头的那一批"。

同一节还并列给出了几条判定原则（台账 R06），一并记住：

• 必须使用最具体的匹配，也就是匹配到的八位组最多、最长的那一条；
• 当allow与disallow的匹配等价（一样长、指向同一处）时，allow应被采用；
• 如果某个 group 里没有任何规则匹配上，或者这个 group 根本没有规则，那么该 URI被允许；
• /robots.txt本身被隐式允许——这是一条有意思的例外：你为了读规则而读规则文件，规则文件自己是允许被读的。

3.2 最长匹配：一条示例讲透

"最长匹配"最容易理解的方式，是看 RFC 自己给的例子（台账 R13）。对 URI

example.com/example/page/disallow.gif

当同时存在Allow: /example/page/与Disallow: /example/page/disallowed.gif两条规则时，必须采用更长的/example/page/disallowed.gif。

注意这个例子里两条规则的"具体性"差异：它们只差几个字符，但机器不会"猜"，它只数从开头起连续匹配的八位组个数，谁多就听谁的。这就是"最长匹配"的全部含义。

顺带把"allow 优先"补上：如果两条匹配一样长，却一条是 allow、一条是 disallow，那就按allow处理（台账 R06）。也就是说，规则冲突时协议选择的是放宽，而不是收紧。

3.3 大小写、百分号编码，还有"该忽略就忽略"

再往下还有两条细节（台账 R07），它们决定了"为什么你手写的规则和机器读出来的结果不一样"：

• 大小写：匹配应当是大小写敏感的（原文用的是 SHOULD，即推荐如此，而非绝对强制）；
• 百分号编码：URL 与规则路径中，ASCII 之外的八位组、以及 RFC 3986 保留范围内的八位组，必须先按 RFC 3986 百分号编码之后再比较；而 URL 中已经是百分号编码的 ASCII 八位组，必须先解码再比较（保留字符与 unreserved 范围之外的除外）。

这两条合起来只说明一件事：读规则要用"机器看到的形态"去读，不能按你眼睛看到的、或者你手敲时的样子去理解。URL 里一个中文、一个空格、一个保留符号，到机器眼里就是另一串东西。

最后一条是"该忽略就忽略"（台账 R08）：不属于任何 group 的 allow / disallow 规则应当被忽略——最典型的例子，就是写在第一条user-agent行之前的那些规则。

本章可以带走的一句：读一条规则只看三件事——从哪开始匹配、谁最长、遇到编码先换回机器视角。

四、取不到 robots.txt 的时候

4.1 4xx：规则文件"不可用"

现在处理一个绕不开的现实问题：如果我根本取不到 robots.txt 呢？

RFC 9309 把"取不到"分成了两种情形，处理方式截然相反——这正是本节最容易读错的地方。

第一种是 4xx。当服务器的状态码表示 robots.txt 对爬虫不可用（例如 HTTP 400–499）时，规范给出的措辞是爬虫MAY 访问服务器上的任意资源（台账 R09）。

注意 MAY 这个词的分量：它是一条允许性的规定——规范没有禁止爬虫在这种情况下访问，它只是不再把 robots.txt 当作设置来用。

4.2 5xx：不可达，MUST 假定完全禁止

第二种是 5xx，处理方式刚好相反。

当 robots.txt 因服务器或网络错误而不可达时，该文件被视为未定义，爬虫MUST 假定完全禁止（complete disallow）（台账 R10）。

而且规范还给了时间维度的补充：如果这种不可达状态持续相当长的时间（例如 30 天），爬虫MAY 改为按"不可用"处理，或者继续使用缓存副本（台账 R10）。

把两节并排看，结论相当反直觉：

也就是说，在协议眼里"服务器出错了、文件没了"不等于"规则消失了"，而是默认全面禁止。这一点和很多人的直觉刚好相反：越是取不到，协议的态度越收紧。

想亲眼看清自己遇到的是哪一种，只需要一个只读动作，把状态码单独打印出来看看：

⚠️代码待验证

curl-s-o/dev/null-w"%{http_code}\n"https://example.com/robots.txt

这里的-o /dev/null表示把正文丢弃、不看内容，-w只把状态码打到屏幕上。看到 4 开头的码，对应"不可用"；看到 5 开头的码，对应"不可达"。这一步只是观察，不改变任何远端状态。

4.3 容错解析、解析上限，以及必须钉死的一句话

再补两条实现侧的细节。第一，解析要逐行容错：爬虫MUST尝试解析 robots.txt 的每一行，并且MUST使用其中能解析出来的那些规则（台账 R11）——不会因为某一行语法出错就整体放弃。第二，解析要有上限：爬虫SHOULD为保护自身设置解析上限，而这个上限MUST 至少为 500 KiB（台账 R12）。

到这里，本章有一个极其容易被写歪的地方，必须单独钉死。

上面所有那些"MAY 访问"“假定完全禁止”“容错解析”“解析上限”，说的是规范对爬虫实现者的要求，不是对网站所有者的建议。它回答的是"一个按规范实现的爬虫遇到这种文件时会怎么做"，而不是"你现在该怎么去抓"。

更要紧的是："能不能访问"和"该不该访问"是两件完全不同的事。规范在 4xx 处说 MAY，描述的是协议层面的自由，它没有、也不打算给出任何"因此你可以去访问"的许可——因为规范本身在第一章就把这件事否掉了（台账 R03，下一章会逐字引）。

所以，本章的正确读法只有一句：这些是"实现怎么工作"的说明，不是"你该怎么行动"的指南。把实现要求读成行动许可，是这一章唯一的致命误读。

本章可以带走的一句：取不到文件时，协议关心的是"爬虫默认怎么做"，它从不等于"你被允许了"。

五、第二层：协议规则不是授权

5.1 逐字原文：规则不是授权

现在进入全篇最核心的一句话。RFC 9309 在第一章 Introduction 的末句，用一句极短的英文，把第一层和第二层一刀切开（台账 R03）：

These rules are not a form of access authorization.

翻译过来就是：这些规则不是一种访问授权。

这一句话，把前面四章讲的所有东西重新定位了一遍：robots.txt 是一份服务方写给爬虫看的声明，它既不是禁令，也不是许可。由此推出两个方向都成立的结论：遵守它，不等于取得了许可；不遵守它，也不自动等于违法。

这两个方向同样重要，任何一边被说成绝对，都会滑向错误。下一章会把它们各自对应到法律层再讲一次。

5.2 措辞里的态度：是"被请求遵守"，不是"获得许可"

如果 R03 还不够清楚，规范在第一章里还有另一处措辞可以作证。它在描述规则对爬虫的效力时，用的词是“are requested to honor”——被请求遵守（台账 R04），而不是"必须获得许可"。

"请求"和"许可"是两种完全不同的关系，值得停一下：

• 许可意味着"你有权做，我同意"——这是一种授权关系；
• 请求遵守意味着"我希望你配合"——这是一种礼貌关系。

规范自己选择了后者。这也就是为什么第一层只能叫"协议规则层"——它的力量来自双方的默契，不来自强制。换个说法：robots.txt 是网站对着爬虫的一次表态，而不是一次批准。

5.3 第二层是另一份东西：网站条款与 API 条款

那么，"授权"这件事在第一层之外归谁管？答案是第二层：网站自己拟定的使用条款。

这一层和第一层有本质区别：robots.txt 是按一份公开协议写的技术声明，而使用条款是网站方自己拟定的、你和网站之间的约定。你的访问行为一旦超出条款允许的范围，性质就从"没配合协议"变成了"违反了约定"。常见的形态包括：

• 网站使用条款里关于"自动化访问"“数据抓取”"账号行为"的那几条；
• 如果网站提供官方 API，那么API 条款是比使用条款更具体的约定——它往往明确写了能怎么调用、能调多少。

第二层的门槛，比第一层低得多、也硬得多：第一层你"没配合"，通常不会有直接后果；第二层你"违反了约定"，对方就可以据此中止服务、追究违约责任。这也是为什么"能抓"和"该抓"必须分开问——第一层回答的是前者，第二层才开始回答后者。

本章可以带走的一句：robots.txt 说的是"我请求你配合"，网站条款说的才是"我们之间的约定"——这是两层，不能混为一谈。

完整版合规边界速查表：覆盖协议规则层、网站条款层与法律层三层的对照关系，和本章讲的"规则不是授权"正好配套，放在资料包里，扫码即可获取：

六、第三层：法律边界在哪

6.1 《网络安全法》：现行禁令在第二十九条

走到第二层之外，才进入真正具有国家强制力的一层。这里有个容易记错的点要先说清楚：《网络安全法》的禁令条款现行是第二十九条（2025-10-28 通过修改决定，2026-01-01 施行），不是过去常被引用的第二十七条。

第二十九条的核心内容，可以拆成三层禁令来记：

• 不得非法侵入他人网络、干扰他人网络正常功能、窃取网络数据；
• 不得提供专门用于侵入等危害网络安全活动的程序、工具；
• 明知他人从事危害网络安全活动，不得为其提供技术支持、广告推广、支付结算等帮助。

把这三层禁令和"爬虫"这个主题对上，关系其实很直接：如果自动化访问越过了"未经授权"这条线，“侵入”“干扰”"窃取"就可能被对应上。反过来说，法律层盯的从来不是"你有没有用工具"，而是"你有没有获得授权、有没有造成损害"。

6.2 《刑法》：两个常见条文

比《网络安全法》更重的一层，是《刑法》。和这个主题相关的主要是两个条文：

• 第二百八十五条：非法侵入计算机信息系统罪；非法获取计算机信息系统数据、非法控制计算机信息系统罪；提供侵入、非法控制计算机信息系统程序、工具罪；
• 第二百八十六条：破坏计算机信息系统罪。

这两个条文的共同点是：它们管的都是**“未经授权"或"造成破坏”**这类情形。换句话说，法律层真正在意的，依旧是"有没有获得授权"和"有没有造成损害"——这一点和上一节《网络安全法》的判断逻辑是一致的，只是层级的轻重不同。

关于量刑，这里只提一句：另有司法解释规定了量化门槛。至于具体的数字门槛——比如达到多少条、多少台——属于另一篇文章已经写透的范围，本文一个数字都不给，免得把"门槛"误读成"目标线"。

6.3 robots.txt 在中国的直接法律效力：本文标"待验证"

最后必须正面回答一个所有人都想知道、但本文**必须诚实说"不知道"**的问题：在中国法下，robots.txt 本身有没有直接的法律效力？

本文的答案是：待验证。截至目前（截至 2026-10-07），本文未核到任何中国法律条文或司法解释直接点名 robots.txt（台账 NB10）。因此在核实之前，有两句话两个方向都不能写：

• 不能写"违反 robots.txt 就是违法"——因为本文没有核到这条依据；
• 也不能写"robots.txt 没有法律效力，所以随便抓"——这是把"没核到直接条文"偷换成了"没有效力"，同样没有依据。

稳妥的表述只能是：robots.txt 属于第一层的协议规则；它是不是、以及在多大程度上能作为法律层的判断依据，截至 2026-10-07 仍未核到直接条文，标"待验证"。把"没查到"说成"没有"，和把"请求遵守"说成"法律强制"，是同一种错误的两面。

本章可以带走的一句：法律层管的是"有没有授权、有没有损害"，而 robots.txt 能否直接充当法律依据，本文标"待验证"，两个方向都不要下结论。

七、三层怎么合起来用

7.1 一张表把三层并排

把前面六章收拢成一张表，后面遇到具体情境，对着表定位就行：

这张表要表达的核心只有一句：三层是三个独立的关卡，通过前一层不自动带到下一层。

实际使用这张表时，顺序建议从下往上核对：先确认法律层没有越线（有没有授权、会不会造成损害），再看条款层是否允许（条款和 API 条款怎么写的），最后才回到协议规则层逐个路径去看 robots.txt。把顺序倒过来——只盯着 robots.txt 判断"能不能抓"——正是本文开篇说的那种"把三层压成一层"的做法。

7.2 一份"只读动作"自查清单

落到动手之前，可以按下面这份清单逐条自问。注意：清单一律是只读的观察与判断，不涉及任何抓取动作。

• 我有没有明确授权？对象是我自己的资产，还是书面授权覆盖的范围？
• 我读懂了这个站点的 robots.txt 吗？（组、规则、最长匹配——第三章那套）
• 这个站点的使用条款里，关于自动化访问是怎么写的？
• 如果它提供官方 API，我是否应该走 API，而不是别的路径？
• 这件事会不会干扰到对方服务的正常功能？

清单里没有一条是"怎么抓"，全是"我站在哪一层、有没有越线"。这正是本文和抓取教程的分界线：教程从"怎么发请求"开始，本文到"该不该发"为止。

7.3 只读观察：怎么把 robots.txt 取回来读

最后给一个只读的观察动作：只是把 robots.txt 取回来看，不发起任何抓取。

⚠️代码待验证

curl-Ihttps://example.com/robots.txt

⚠️代码待验证

curl-shttps://example.com/robots.txt

第一条用-I只取响应头，用来观察这个文件在不在、返回什么状态码——正好对应第四章那两种情形；第二条把正文取回来阅读。example.com是保留的示例域名，这里只用来说明"取回来看"这一步，不指向任何具体站点。

再强调一次：取回来看是在读规则；本文到此为止，不写任何"取回来之后怎么发请求"的东西。

本章可以带走的一句：动手前先过一遍三层和这份只读清单，把"我能做"和"我该做"分开回答。

完整版三层边界对照表：把协议规则层、网站条款层、法律层三层的判定要点与自查清单整理在一张表里，和本章的收尾正好呼应，放在资料包里，扫码即可获取：

附表 A：本文引用事实与官方出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，把 robots.txt 背后的 RFC 9309 原文逐条对着读了一遍，才发现"规则不是授权"这句话早就写在规范第一章里，顺手也整理了几份配套的东西：

• 三层边界对照表：协议规则层、网站条款层、法律层三层的判定要点与自查清单
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「靶场」，优先通过。

拿到之后建议先看三层边界对照表那一份，把"规则、条款、法律"三层的关系先理顺，再动手做任何自动化的事。