Is it enough to just put all the URLs in Sitemap.xml? A good Sitemap should only submit "pages that you really hope to be indexed by search engines".

Many CMS systems will output all the tabs, search pages, filter parameters, draft addresses and canonical duplicate pages to the Sitemap. The result shows that the XML appears very complete, but it is actively submitting a batch of URLs to the search engine that it does not even want to be indexed.

01 The role of Sitemap is to discover prompts, not to force inclusion lists

Google's current documentation uses Sitemaps as a way to help search and discover URLs, which is particularly suitable for large, new websites, those with weak internal links, or websites rich in media.

Submitting a Sitemap does not guarantee that the URL will definitely be crawled and indexed. The page itself still needs to be accessible, valuable and meet the indexing conditions.

02 Only place canonical, indexable URLs that are expected to appear in the search

If a page noindex, is redirected, 404, or canonical points to another address, it should not continue to appear in the main Sitemap.

Submitting conflicting URLs to the search will only increase troubleshooting noise. A Sitemap should be the "preferred collection of pages" that a site presents to the outside world.

03 lastmod is only valuable when it is actually updated

Many systems write the lastmod of all URLs as the current day each time they generate a Sitemap, which is equivalent to telling the search "The entire site has just been updated". Such data loses its meaning if it is not reliable.

lastmod should be updated when the main content undergoes substantial changes, rather than the generation time of the Header, statistics script, or Sitemap itself.

04 Large websites need to split sitemaps and use indexes

Google's current specifications support a maximum of 50,000 URLs for a single Sitemap, with an uncompressed file cap of 50MB. After exceeding, it needs to be split and summarized through the Sitemap Index.

Even if the upper limit has not been reached, it can still be split by content type: products, articles, cases, and videos, which is convenient for monitoring the indexing issues of different page groups.

05 Sitemap cannot remedy poor internal links

A page that only has a Sitemap and no crawlable links within the site may be found through search, but it is also very difficult for users to reach it naturally.

The core page should still be structured through navigation, categories and internal links in the main text. Sitemap is a supplementary discovery mechanism, not a replacement for information architecture.

06 Multilingual websites can place hreflang in HTML or Sitemap

Google supports declaring language/region variants through Sitemaps, but the maintenance complexity is relatively high. No matter which method is chosen, it is necessary to ensure that the two-way relationship and the URL are consistent.

Do not maintain multiple conflicting hreflang data sources simultaneously.

07 Search Console after submission, the focus is on the exception, not "Submitted successfully"

A normal Sitemap status only indicates that the file can be read. More importantly, the URL, index override and the actual state of the page have been discovered.

If 20,000 product pages are submitted and only 2,000 are indexed over a long period of time, it is necessary to return to the issues of content quality, repetition, internal links and crawling instead of submitting repeatedly every day.

08 The CMS should automatically maintain the Sitemap, but the rules must be defined by humans

Automatic generation can prevent manual page omissions, but "which types should be included" requires a joint decision by SEO, content, and development.

Each time a new template, filter page or multilingual version is added, the Sitemap rules should be evaluated to prevent the number of URLs from getting out of control quietly as the functionality grows.

09 Sitemaps can be split, but the splitting rules must serve the operation

Large websites often break down products, articles, cases, and multilingual pages into multiple Sitemaps, which are then aggregated by Sitemap indices. This is not only done to break through the quantity limit, but also to facilitate the team's observation of which types of URLs have commit and index anomalies.

The splitting method should be consistent with the content lifecycle. Although it is technically feasible to randomly cut 10,000 pieces every day, it is not conducive to locating the problem. Organizing by content type, language or business line is usually easier to maintain.

10 Do not mistake "committed" for "should be indexed"

Sitemap is for discovering and normalizing signals, not an application form for inclusion. A weak, repetitive, no-indexed, redirected or incorrectly returned URL will not obtain a stable index even if it is submitted every day.

The real investigation should return to whether the page is accessible, independent and valuable, whether the canonical is correct, whether internal links exist, and whether the server is stable.

Frequently Asked Questions

Will submitting a Sitemap speed up indexing?

It can help discover URLs, but it cannot guarantee crawling and indexing. Page quality and site structure remain important.

Can a Sitemap contain noindex pages?

Not recommended. Sitemap should give priority to including the canonical URLs that are expected to be indexed.

Is it better to update lastmod every day?

No. The true modification time of the main content should be reflected. False updates will reduce the value of the signal.

What is the maximum number of URLs for a Sitemap?

Google's current documentation stipulates that a single Sitemap can have a maximum of 50,000 URLs, and the uncompressed size should not exceed 50MB.

Is it necessary to place the Sitemap link in the robots.txt file?

Ok. It can also be submitted through Search Console. Both methods can be used simultaneously.