The proportion of AI crawler interception changed between two months, is it changed by the default value of the platform or the webmaster?
The domain names in the same batch have changed the intercept rate of AI crawlers in two months, is it the platform default value changed or the webmaster changed the configuration himself? In most cases, it is the former. The method of distinction is not guessing, but looking at the direction of change: the same batch of samples are measured once every two months, with the platform default value going online in the middle, and the displacement is concentrated on the side of training and proxy types, while the retrieval type did not move much. If the webmaster changes his own robots file one by one, the proportion of several manufacturers should vary randomly, and will not present such a synchronous rhythm.
What happened between the two measurements?
2026-10-30 The original text opened for verification states: This AI crawler blocking index was measured twice in July and September, covering 10,894 domains. The change that went online between the two measurements was described very clearly: Starting from September 15, 2026, new domains connected will receive new default values, and crawlers classified as training and proxy types will be blocked by default on advertising pages, while retrieval types will continue to be allowed.
The scope of the default value is declared, covering only new domains added, and the proportion of the whole batch of samples still moved. The reasons are twofold: first, the new domain enters the sample with a new default value, which is a structural shift; second, some webmasters follow the same template in bulk to change the configuration, which is the part that webmasters are truly responsible for. When looking at your own site, the two things should be calculated separately.
Align the口径 before comparing
There are two different apertures in the same statistical data. At the site level, the domain blocking GPTBot accounts for 7.9%, and blocking any AI crawler accounts for 10.3%; in the news release industry, these apertures are raised to 50.5% and 56.4% respectively. When comparing the difference over two months, it is necessary to lock the same aperture: taking the later value of 'blocking any one' and comparing it with the earlier value of 'blocking only one', will result in an increase that does not exist.
The industry is stratified similarly. The content itself is a high stock in the industry, and the overall average does not have an explanatory power for it; conversely, using the numbers of the news industry to measure your own product documentation site will treat normal conditions as anomalies. The composition of the industry in the sample changes, and the average will also change, which has nothing to do with the decision of a single site owner.
Why should training and retrieval be separated
The uses of the two types of crawlers are different, as are their costs. Training-type collection is a one-time bulk data acquisition, and blocking it reduces an opportunity for model referencing and also reduces potential referral traffic; search and real-time retrieval types often bring real users, and blocking them is equivalent to shutting off the entry from generative answers. Combining the two into an 'AI crawler' switch, the numbers will fluctuate with the platform's default values, and webmasters will find it difficult to determine what they have actually turned off.
In a self-built program, a more convenient layered approach is to assign three types of uses to configuration: the robots file is written to clarify handling by user groups, llms.txt determines whether the content is aimed at large language model organizations, and GEO-related visibility standards are confirmed separately. Each layer handles a segment, and changes can be attributed accordingly.
The three configurations that the webmaster really needs to adjust.
One is the control file itself: grouped by user group, give handling to training classes, proxy classes, and retrieval classes, do not block the entire section. One is the classification switch on the platform side: the new default value only manages new接入 domain names, old domain names need to confirm the current effective value themselves, rather than assuming it has already taken effect. There is also one at the internal exit: the visibility of the site entrance, llms.txt, and the text page should be consistent, do not appear the index entrance is blocked while the text is allowed to pass, or vice versa.
After changing it, don't just look at the configuration text, but also look at the real return. Record the request volume and return status of three types of proxies separately, and move one layer at a time. If you change three layers at the same time, the result cannot be attributed, and it will still be guessing next time you encounter the same displacement.
Common questions
Q: Has someone changed the configuration if the intercept ratio has increased? A: Not necessarily. New domains entering the sample with the default value of the platform can also cause overall displacement.
Q: Is it enough to only change the robots file? A: Not enough. Robots is a polite guidance, and mandatory interception occurs at the platform or rule level, and both places need to be confirmed together for the current effective value.
Ask: Should the retrieval class be stopped together? Answer: First, see if the requests it brings have entered the station and converted. Most content sites will allow the retrieval class separately, only tightening the training class.