The site map entries are almost at the limit, how to arrange the submission order after splitting into index files?

How to arrange the submission order after splitting the site map entries into index files when they are about to exceed the limit? The answer is to split first, then hang, then submit: the split files are first generated and can be accessed independently, then the split addresses are hung into the index file, and finally only the index file is submitted to the crawling entry. The limit of a single file is determined by two lines: the number of entries and the volume. Any line that comes first should be handled.

How is the limit of a single file determined?

The official statement is: a sitemap file can contain up to 50,000 addresses, with an uncompressed size not exceeding 50 MB. The line that collides first is the one to be counted - when the column URL is short but the number is large, it is usually the number that collides first, and it is easier to collide with volume when long paths and Chinese character encoding are involved.

Confirm first whether the sitemap is automatically generated before splitting. A handwritten list is bound to be missing when the entry quantity increases, and only the pieces generated automatically can grow in sync with the release action.

What granularity should be split by?

Cut by column, do not cut evenly by number. The reason is that the column boundary is stable, new content will only fall into a few slices, and the changes are small; cutting evenly will scatter articles of the same theme into multiple slices, and any batch adjustment requires rearranging all files.

For blogs with a large number of single articles, you can cut the archives by year and month; for corporate websites, the product center, news, and downloads are more intuitive when each component is a slice. In a multi-site scenario, each site should produce its own slices, do not merge them into a single file, otherwise, the changes of a single site will affect the crawling records of other sites.

The submission order of index files and slices

The order is wrong, a common manifestation is that the slices are accessible but the crawling volume does not increase.

• Firstly, request each slice individually to confirm that the return is normal, the encoding, and the pseudo-static rules have not blocked XML into HTML pages.
• Then, in the index file, list the slice addresses one by one, the index file itself is also constrained by the number of items, and an additional layer must be split when the number of slices is large.
• Finally, submit this address of the index file only, the crawling entry will read the slices along it, and there is no need to submit each slice individually.
• After submission, leave a few days to observe. Repeatedly submitting the same batch of addresses in a short period of time will not accelerate it, but will only make the crawling records chaotic.

How to push after the new content is generated

The sitemap manages the whole site address, don't miss it, and the link push manages to make this new address seen as soon as possible. The two things should not be mixed. After a new article is published, go through Baidu push and Bing's active push interface, and push the incremental data every day; the sitemap is responsible for periodic bottom-up full amount, so that both of them cooperate to prevent only relying on the map to slow down the collection.

When changing the address, add a 301 redirect to converge the historical URL to the new address, and then let the new Sitemap reflect the final form, so as to avoid leaving both old and new sets of addresses in the map.

Common questions

Do you need to resubmit all files after splitting?No, you can submit the index file only, the slices are read based on the index.

Is the limit a hard limit or a recommended value?If exceeded, the file is likely to be ignored as a whole, splitting according to the limit is more stable.

Can multiple sites share the same index file?Not recommended, sites affect each other, crawling and problem location are more difficult.