报错出现时我们看到了什么
2026 年 9 月 27 日我们往百度普通收录接口推一批城市分站 URL，请求发出去之后直接收到 400，错误信息显示 site init fail。起初以为站点配置有问题，但域名和协议都正常可访问。后来把请求原样打印出来，发现 site 参数被脚本做了一次 URL 编码，值从 site=https://x.com 变成了 site=https%3A%2F%2Fx.com。
百度普通收录接口不会对这个参数做解码，拿到编码后的字符串认不出站点名，于是返回 400。这个接口对 site 参数的要求很直白，必须给原始串。我们写脚本时习惯对整个参数列表做一次 encode，没把 site 单独摘出来。事后看这个坑很小，但报错信息只给 site init fail，没直接提示编码问题，排查花了时间。
两种请求形态的对照
错误请求形态里 site 参数的值是 URL 编码后的内容，比如 site=https%3A%2F%2Fx.com。接口收到后不解码，拿到的字符串里没有正常协议和域名分隔，站点比对直接失败，返回 400 site init fail。
正确请求形态是 site=https://x.com。协议，双斜杠和域名都保持原样。其余参数可以按正常规则编码，但 site 必须例外。这个接口需要的就是原始站点串，不能多给任何转义。
两个形态差别只在 site 参数是否被 encode。看起来更规范的写法是把所有参数值都编码一遍，防止特殊字符干扰。在百度普通收录接口这里，site 不参与解码，编码反而破坏了源串。
为什么规范写法反而错
通常做接口对接，把参数值做 URL 编码是减少歧义的常规操作。每个接口对参数的处理方式不同。百度普通收录接口对 site 字段的处理是直接拿原始字符串去匹配站点库，它没有先解码再匹配这一步。编码后的字符串虽然合法，但不是它认识的站点标识，所以 site init fail。
我们记下来的判据是 site 参数一个字符都不能编码。一旦编码，接口立刻 400，没有其他报错提示。这个规则只在百度普通收录接口验证过，其他百度接口或外部平台不适用。
URL 编码的常规做法是防止空格，斜杠，冒号这些字符干扰请求结构。site 参数本身的使命是携带站点原始串。百度普通收录接口把这一层判断放在解码之前，编码之后等于传了一个错站点名。
两次踩坑和修正记录
这个坑我们踩了两次。头一次是 2026 年 9 月 27 日，当时改好了推送脚本，把 site 参数从自动编码列表里摘出来，直接拼接原始值。后来 9 月 30 日写另一个新脚本，又按老习惯把 site 一起编码了，请求一发出还是 400。再次看到 site init fail 才反应过来，把 site 改回原始串，请求才正常通过。
两次踩坑后我们把这条写进城市分站的判据记录里，提醒后续写任何百度收录推送逻辑时，site 参数一律不准做 encode 处理。判据记录里留着这两个日期，方便回溯。
处理本身不复杂，就是定位到 site 参数，保持原始串。不同的是排查方向。头一次知道是编码问题，直接改掉就行。后来一次因为换了脚本，没有复用同一个函数，又踩了一遍。现在不管是新脚本还是老脚本，只要对接百度普通收录接口，site 这一项都单独处理，不做 URL 编码。
结果与边界
修正后百度普通收录接口不再返回 400，请求能通过。我们只确认到接口接收这一步，没有去追后续收录效果。接口返回成功只代表请求被接收，不代表页面一定收录或获得排名，这一点不承诺。
边界很清楚：site 参数不编码这个结论来自百度普通收录接口的实测，两次错误和两次修正都指向同一原因。换到其他接口或其他平台，site 参数是否需要编码要单独看文档，不能直接套用。
桐灼做全域 AI 搜索的 GEO 优化，平时对接搜索平台接口和站点收录时会留下这类踩坑记录。如果你也在推城市分站或企业站群，遇到类似 site init fail 的报错，可以先检查 site 参数有没有被做过 URL 编码。有接口对接和 GEO 落地需求可以找桐灼（淄博）网络科技有限公司，电话 17852030756。