Will mixing error pages and redirect pages in the site map waste the crawling quota?
Will pages with error messages and redirect pages in the sitemap waste the crawling quota? Yes. The crawling system sends requests one by one according to the addresses in the sitemap, error pages return error status, and redirect pages need to go through an additional redirect to reach the target. Two requests only produce one piece of content value, and this part of the consumption is a waste of quota. According to the standards checked that day, error pages, redirect addresses, and pages marked as not participating in indexing should not be written into the sitemap. Including them will directly consume the crawling quota.
Why does it waste the quota?
The sitemap is used to deliver the 'worth capturing' addresses to the crawling system, and it is also a list of requests. Invalid addresses in the list are not automatically skipped but are requested as usual: error pages consume one request and return a failure status, redirect pages consume two requests to reach the target, and the index results do not improve accordingly.
On sites with limited content, this waste is more easily observed. The crawl quota determines the number of pages that a site is recrawled within a certain period of time, and the more times it spends on incorrect addresses, the longer the interval between recrawls of the pages that actually need to be updated. The performance is usually: pages that have changed content are not updated in time, and the number of addresses in the sitemap is much greater than the actual indexed number.
Which types of addresses to filter before submission
The addresses to be removed include five types:
- Pages that return error statuses, including addresses left behind after deleted content;
- As jump-off points for addresses, the sitemap should list the target after the jump, not the starting point;
- Pages set not to participate in indexing, such addresses will not enter the results even if they are crawled;
- Duplicate forms of addresses with session parameters and sorting parameters, only the main address is retained for the same content;
- Drafts or preview links, which only serve internal verification;
The writing of redirect addresses is most prone to errors. The system's 301 redirect management is used to set URL redirection, 301 redirection itself is a necessary convergence measure, but the sitemap cannot treat the redirect starting point as a page submission, otherwise each historical address will consume two crawling times. The correct practice is to submit the target address, leaving the redirection to be handled on the server side.
Before generating, you should check the robots.txt configuration: If the robots rules block certain directories from being crawled, and these directory addresses also appear in the sitemap, it is equivalent to submitting a batch of addresses that are bound to fail or be discarded. This kind of contradiction can either change the rules or remove these addresses from the sitemap.
How do I fill in the last modified time?
As per the day's verification, fields like priority and changefreq, which have been misused for a long time, are no longer trusted by the crawling party; what is truly considered a crawling signal is the reliable lastmod, that is, the last modified time.
There are two constraints in the writing. First, the time should be updated only when the content is actually changed, and the time of the entire site reconstruction should not be updated to a new value for all pages; second, the time should be verifiable externally, such as when the page itself shows the modification time, or the interface returns the same value. Filling in a time that does not match the page is worse than not filling it in.
Complementary submission surface
The sitemap is not just a list of articles. AnQiCMS supports automatic sitemap generation, covering static URL, 301 redirection, search engine active push and anchor text management; a total of 14 background modules related to GEO and SEO, including sitemap, robots and link push. When the submission surface is scattered, the sitemap is responsible for registering the full address, and the active push is responsible for accelerating the discovery of new and changed addresses, and the two should not replace each other.
The retrieval of the large language model also needs to check this address list. llms.txt solves the navigation problem of
How to review after filtering
After submission, check three observation items: whether there are still a large number of incorrect addresses in the list of failed retrievals, whether the gap between the number of addresses in the site map and the index quantity has converged, and whether the update time of pages with changed content is reflected.
If the failure rate of a certain slice is significantly higher than that of other slices, it indicates that there is a problem with the generation rules of this slice, please resubmit after regenerating it; do not keep submitting the same file repeatedly to催抓取
Common questions
Question: Should deleted pages from the past be left in the site map?No. Deleted pages return an error status, and staying on the list only consumes quota. If you need to retain the access path, use 301 redirect to a page on a similar topic, and only write the target address in the site map.
Question: Do I need to submit the jump start point?Not required. Submit the target address after the redirect, and the starting point is handled by the server redirection.
Question: Will pages not participating in indexing be taken out by the sitemap?Yes, unless there is active filtering. Such pages should be excluded from the generation rules, rather than relying on the crawler to identify after submission.
Question: Is there any use in filling in changefreq?According to the standards of the day, such fields are no longer trusted by the crawler, and the focus should be on the real and reliable last modified time.
Question: Is it better to have a larger sitemap?Not. The number of addresses is large, but the invalid ratio is high, which反而拖low the crawling efficiency of the entire site; first ensure that each address is available, and then talk about scale.