Does the update frequency and priority in the site map still affect inclusion?
Does the update frequency and priority in the sitemap still affect inclusion? The current situation of these two fields is: Google and Bing have confirmed that they ignore them, and writing them in the map does not change the crawling schedule. What will truly be read and affect behavior is the last modification time of each URL. Shifting the focus of maintenance from adjusting frequency and priority to writing timestamps honestly and clearing out addresses that should not be there is the effective investment in this matter.
The actual function of the two fields now
changefreq originally wanted the site to tell the engine 'This page is updated every day', priority wanted the site to indicate 'The homepage is more important than inner pages'. The problem is that the engine does not trust the self-reported data from the submitter: the crawling schedule depends on its own observed historical change rhythm and link weight distribution, and the self-reported values may be misused or lack verification.
Dyno Mapper comes to a very direct conclusion in the **practice of site maps: for Google and Bing, the answer is to ignore, both have confirmed that they do not read these fields. Therefore, the premise of questions like 'Would increasing the priority from 0.5 to 1.0 improve inclusion' does not stand.
Why should lastmod be honest?
In the same document, another key point is: In the single address attribute of the sitemap, the last modified time is the one that truly has a substantial impact on Google's crawling behavior. Its credibility lies in the verifiability - when the page content changes, the timestamp should change; if it doesn't change, pushing new content forcibly will instead cause the engine to reduce its trust in the entire file.
There are three disciplines in practice. First, update the time only when there are actual changes in the text or structured fields, do not refresh the website timestamp in bulk for template adjustments. Second, when importing historical content in bulk, the time should be taken from the content's own modification time, not the import time. Third, automatic generation should be based on data layer records, not on script traversal of the page to output.
Why can't the jump page and error page stay in the diagram?
After the update, old addresses are often still in the sitemap, actually returning redirect or invalid pages. These addresses take up file volume, causing the crawling quota to be spent on pages that do not need to be indexed, and will also reduce the credibility of the entire file. Nightwatch's suggestion is clear: do not index pages marked as not participating in indexing, redirect addresses, and error pages that return invalid status codes.
The method is not manual deletion, but to tighten the generation conditions: only output links with normal status, allowed indexing, and pointing to the final address. AnQiCMS's site map is automatically generated,配合 301 redirect management, when the site is revised, the old addresses are set up to point to new addresses with redirect rules, the generator generates maps according to the current valid addresses, and such dirty addresses will naturally not enter the map.
The order of generation and maintenance
The wrong order will lead to repeated rework. The reasonable way is to first do the static and address rules, confirm the stability of the page address; then check the redirect mapping, converge the historical addresses into the final form; finally, let the sitemap be automatically generated according to the rules and connect the push.
The notification of new content is another matter: the sitemap solves the full amount of backup, and the active push solves the problem of 'the newly published articles being found as soon as possible'. AnQiCMS's link push management supports the active push of Baidu and Bing, both of which should work together instead of replacing each other, don't expect one to be done and the other can be ignored.
The file size is also limited, a single sitemap file has a limit on the number of addresses and volume, and if it exceeds the limit, it should be split into multiple files and summarized with an index file instead of being crammed into one file.
Common questions
Should these two fields just be deleted?Keeping the default value does not affect anything, deleting or not deleting does not change the result. The focus should be on timestamps and address quality.
The sitemap has been submitted but there is no change in inclusion, what should be checked first?First check the page itself: is it marked as not participating in indexing, does it have duplicate content, or does it not have any internal links pointing to it? Most inclusion issues are related to the discoverability of the page, not the submission action.
How often is it appropriate to update the sitemap?Let the generator follow the content, refresh when there are new pages or real modifications. Running the entire site timestamp on a fixed schedule actually reduces credibility.
Should images and attachments be shown separately?It is worth having a separate one when there is a demand for image traffic, with the same conditions of valid address and honest timestamp.