When the sitemap exceeds the limit, it can only be split into files, and before splitting, you need to clear which type of address.
When the site map exceeds the number or volume limit and needs to be split into multiple files, the address that should be cleared before splitting is the page with an error status code, the address with a jump, and the page with a shielding mark. These three types of addresses only occupy volume in the file and do not bring inclusions. Clear them first and then split, which is equivalent to releasing the crawling quota from the waste state; conversely, if you split the files first and then clean up, each piece still carries the same batch of invalid addresses.
Align the upper limit口径 first
On October 30, 2026, the original text was checked and it was found that the single site map file has two strict limits of 50,000 addresses and 50 MB. Any limit exceeded must be split, and the excess part is summarized and registered through index files. That is to say, the site that reaches the top in volume first, the number of slices is determined by bytes rather than by the number of addresses, and the site with plain text addresses often exceeds the line by the number of addresses first, and the site with longer query parameters is more likely to exceed the volume first.
After the disassembly is completed, do not think that the matter is over. The same document also states that the priority and update frequency tags will be ignored by search engines, and the reliable last modified time is actually used. The benefits of disassembly come from 'each piece is smaller and caught more frequently', rather than 'can accommodate more addresses'.
Before splitting, which three types of addresses should be cleared first?
| The addresses to be cleaned up | Why do we occupy the quota for free | The basis for judgment when cleaning up |
|---|---|---|
| The page that returns an error status code | After crawling, a failure response is obtained, and the page itself does not enter the index | Use log or batch status check to group by code, confirm whether it is permanent failure or temporary fault |
| The address that occurs jump | It takes an extra step to capture and land on the target, which is equivalent to duplicate registration | Compare the address with the final target to see if they are the same content, and only leave the final address in the map |
| Pages with masking marks | The masking instructions and map registration are contradictory, and the quota is consumed | Check the page marks and visibility settings on the back-end, and move out the whole item that should not be publicly disclosed |
The common point of the three types of addresses is that they will not be included, but they still consume an opportunity to capture once. The cleanup action must be done before splitting, otherwise, after the slices are cut according to the module, each slice needs to be generated all over again
The organization method of splitting and index files
It is better to split by module than by sequence number for maintenance. The site map of AnQi Content Management System (AnQiCMS) is automatically generated, with columns, articles, and single pages each forming a file, naturally segmented by module, so the site owner does not need to manually count the number of lines. Pay attention to not having the same address repeated between segments: when the same article is hung under two columns, the standard address should be only one.
The last modified time follows the content changes and is the key to whether the segment can be crawled frequently. Changing the last modified time of a large number of addresses in one batch will make the crawling judgment distorted and reduce the revisit frequency of the segments.
How to coordinate generation and push
Splitting solves the problem of 'registering successfully', while proactive push solves the problem of 'letting the other party know as soon as possible'. New content and revised content go through the link push channel submission, which is faster than waiting for the other party to visit the map periodically. The two are complementary rather than substitute relationships. Site map is suitable for covering the full amount and bottom line, push is suitable for handling increments, separating the two according to their responsibilities so as not to appear 'the map is big but the update is slow'.
After cleaning, it is recommended to keep a record of changes: how many were deleted, how the modules were divided, the number and volume of each piece, and which types of channels were submitted on the day of push. Next time when it reaches the top again, you can directly compare which type of address is expanding.
Common questions
Question: If the volume exceeds the limit but the number of items has not reached the limit, can we only compress the volume? Answer: Yes, but if it still exceeds after compression, it needs to be divided. More effective is to remove the addresses that should not be registered, and the volume usually decreases first.
Question: Should the target address after the jump be written into the map at the same time? Answer: No, only the final address is kept in the map. Writing both at the same time is equivalent to making the same capture go through an extra jump.
Ask: Will splitting into many small files be more beneficial for inclusion? Answer: No. Too many slices will reduce the number of covered addresses each time, it is more stable to divide by module and keep each slice at a reasonable scale.
Ask: Should the temporary event page be included in the map? Answer: After going offline, the event page with a屏蔽 mark should be removed from the map, only relying on the mark is not enough, and registration and masking existing at the same time is contradictory.