About one in ten sites that are directly rejected by the crawler, should we check robots or service configuration first?
Almost one in ten sites block spider requests into a status code of rejection. When checking, you should first look at the server configuration and then the robots file, as their mechanisms of action are different: the robots file is a polite guidance, no matter how strict it is, it will not cause the request to return a rejection code; once the crawling party receives a rejected status, blocking must occur at the service layer or rule layer, and changing the robots will not change the result.
The flow and rejection ratio in the day's aperture
On October 30, 2026, the distribution of a group of traffic verified from the original text is: Googlebot accounts for 23.80% of the crawling requests, another meta tag class proxy accounts for 13.28%, and the two agents doing model training and retrieval are 13.23% and 8.05% respectively; In the same statistical data, the proportion of traffic rejected with 403 is 7.9%, close to 10%. These numbers indicate two things: The blocked sites are not isolated cases, but a normal state; The blocking occurs at the service layer, so the form of expression is status code rather than guidance生效.
Read clearly first: The error code is returned by the visited party, and the guidance is voluntarily observed by the other party. Reversing the troubleshooting order will result in the illusion that traffic is still the same after modifying the robots file.
Each layer has its own characteristics of three-level denial.
| Interception layer | Typical return | Observable characteristics | What should be confirmed first? |
|---|---|---|---|
| robots guidance layer | Normal status code, the request does not occur | There is no corresponding path access in the crawling record | Is the path written in the prohibited section? |
| Rule and Protection Layer | Deny status code or verification page | Browser accessible from the same address, proxy caught | Whether the proxy identifier is on the blacklist |
| URL rewrite layer | Deny or not found | Parameterized address is normal, static address caught | Which type of request does the pseudo-static rule take effect on |
Self-check order layered by status code
The first step is to group the crawling log by status code: first look at how many requests fall into the deny code, and then see which paths and prefixes these requests are concentrated. Concentrated in a few prefixes is usually directional interception by the rule layer; scattered throughout the site and related to the proxy identifier are often batch interceptions by the protection layer according to the proxy list.
In AnQiCMS and similar self-built programs, the robots file and URL rewriting rules are two independent entries: the former controls which paths are not recommended to be crawled, and the latter determines the address form in which the same content is accessed. Changing the pseudo-static rules can easily affect the crawling path, so don't ignore this layer when investigating.
How to verify after the modification
The most convenient way is to leave verification records grouped by proxy. Record the request volume and return code distribution of each search proxy and training proxy separately, test one layer after changing one layer. Change only one layer at a time: change the robots section, whitelist, and rewrite rules at the same time, and the results cannot be attributed. Next time, when the same problem occurs, it is still guessing.
If you really want to intercept a certain type of proxy, align the interception action with the purpose: if you just want to reduce the content collected, using guidance and干扰 codes such as content layer means is more controllable; only in the service layer should you return a refusal code and reserve a fallback position to completely refuse access.
Common questions
Ask: Can modifying the robots file prevent training agents? Answer: Cannot guarantee. Guidance relies on the voluntary compliance of the other party, and the return code is the mandatory result of the service layer.
Ask: The browser access is normal, but the proxy gets a rejection code, where is the problem? Answer: First, check whether the rules and protection layer have distinguished according to the proxy identifier, which is the most common cause.
Ask: After changing the rewrite rule, the crawling volume has decreased, how to locate it? Answer: Compare the distribution of return codes between static addresses and parameterized addresses, if only static addresses are captured, the rewrite rule is a suspect point.