XML Sitemap Optimization: URL Priority, Update Frequency, and Submission Strategy
1. What a Sitemap Actually Solves
Many people misunderstand sitemaps. They think submitting one will boost their rankings or get their pages indexed. In reality, a sitemap is just a page inventory. It tells Google, “Here are my pages, feel free to take a look.” Whether Google crawls them, whether it indexes them after crawling, and where they rank after indexing are all decisions a sitemap has no say in.
A sitemap is genuinely useful in three situations. First, when a new site or new page hasn’t been discovered through internal links yet, a sitemap helps Google find it faster. Second, when a site has many deep pages (four or more clicks from the homepage) and Google crawls them infrequently, a sitemap shortens the discovery path. Third, for special content types like video, images, and news, a sitemap can carry extra metadata. For a site with fewer than 500 pages and a solid internal linking structure, the marginal benefit of a sitemap is actually quite low.
| Sitemap Myths | Reality | Rationale |
|---|---|---|
| Submitting a sitemap improves rankings | It doesn’t affect ranking algorithms, only discovery speed | Google’s official sitemap documentation |
| Higher priority means pages rank higher | Google has explicitly said this tag carries very little weight | Google Webmaster Central 博客 |
| changefreq=always makes Google crawl daily | Google doesn’t use this tag to decide crawl frequency | Same as above |
| Every page should go in the sitemap | Only include valuable pages; thin pages hurt more than help | Google Search Quality Evaluator Guidelines |
| Once submitted, you can forget about it | You need to check the GSC report weekly | Real-world operations experience |
How it relates to other SEO modules: a sitemap is Google SEO one layer of the technical foundation, used together with robots.txt configuration—declare the sitemap location in robots.txt, and list important pages in the sitemap. And with internal link structure They complement each other: internal links pass authority between pages Google already knows about, while a sitemap helps Google discover new pages.
2. What belongs in a sitemap, and what doesn’t
Not every URL belongs in your sitemap. A sitemap tells Google which pages on your site are worth indexing. Including pages that shouldn’t be there tells Google those thin pages matter too.
| Page type | Include in sitemap? | Why |
|---|---|---|
| Product detail page | Include | Core conversion pages that need to be found fast |
| Category / section pages | Include | Topic hub pages that carry strong link authority |
| Blog post page | Include | Content pages whose rankings depend on long-tail keywords |
| About us / Contact pages | Include | Trust pages, few in number, no cost to include |
| Tag archive pages | No | Thin content that duplicates category pages |
| Filter result page | No | URLs with parameters: duplicate content that wastes crawl budget |
| Internal search result pages | No | No real content; Google explicitly says not to include them |
| Paginated list pages from page 2 onward | No | Let Google find them on its own via rel=next/prev |
Example 1: A B2B ecommerce site has 30 filter dimensions on its product listing pages (material, size, industry, and so on), and every filter combination generates its own URL. The operations team put all of these filter pages into the sitemap, and the total jumped from 500 to 5,000. The result: Google spent a large share of its crawl budget on near-duplicate pages, crawled the real product detail pages less often, and the overall index rate went down. The fix: remove every parameterized filter URL from the sitemap and keep only the main category pages and product detail pages.
Sitemap size limits: a single sitemap file can hold up to 50,000 URLs and must not exceed 50MB (uncompressed). Beyond that, split it into multiple sitemap files and organize them with a sitemap index file. Most small and mid-sized sites (under 500 pages) need only one sitemap, no splitting required.
3. priority, changefreq, lastmod: which ones matter and which don’t
The Sitemap XML format has four tags: loc (the URL), lastmod (last modified date), changefreq (update frequency), and priority. Google only reads the first two seriously; the last two are largely ignored.
| Labels | Role | Does Google read it seriously? | Recommended Wording |
|---|---|---|---|
| loc | The page URL | Yes, required | Absolute URL including https |
| lastmod | Date the page was last modified | Yes, used to decide how often to recrawl | Enter the real modification date, format YYYY-MM-DD |
| changefreq | Expected update frequency | Barely read | Can be omitted; including it does nothing |
| priority | Relative priority 0.0-1.0 | Barely read | Can be omitted; 1.0 for the homepage and 0.8 for the rest is fine |
Counterintuitive truth: plenty of guides tell you to set priority=1.0 for your homepage, 0.8 for category pages, and 0.5 for posts in your sitemap, assuming Google will crawl them in that order. In reality, Google said back in 2008 that the priority tag carries very little weight, and in 2015 confirmed it basically ignores it. Whether you write 1.0 or 0.1 makes no difference to crawling or rankings. What actually drives how often Google recrawls you is the lastmod tag and a page’s real update history.
How to write lastmod correctly: put the date the page’s content actually last changed. Don’t stamp every page with today’s date. Google will crawl next time, see nothing changed, and trust your sitemap less. If a product page hasn’t been touched in six months, set lastmod to the date six months ago. If a blog post hasn’t been edited since you published it, set lastmod to the publish date. If you refreshed a post with new content, set lastmod to the update date.
Example scenario two: a content site uses the WordPress Yoast plugin to generate its sitemap automatically. By default the plugin sets lastmod to the current date for every page. Google crawls once a week, sees the content hasn’t changed, and after four crawls in a row it lowers its trust in the site’s sitemap, stretching the recrawl interval from 7 days to 30. The fix: change the plugin settings so lastmod uses WordPress’s post_modified field (the post’s last modified date) instead of the current date.
4. Submission strategy and verification workflow
Generating a sitemap isn’t the end of it. You have to submit it to Google and keep monitoring it.
| Steps | Action | Tool / Location | Frequency | Pass criteria |
|---|---|---|---|---|
| 1. Generate the sitemap | Auto-generate (plugin / script) | /sitemap.xml path | Updates automatically after each new post | Returns 200, valid XML |
| 2. Declare it in robots.txt | Add a Sitemap: directive at the end of robots.txt | /robots.txt | Only once, as long as the sitemap path stays the same | Google can find it via robots.txt |
| 3. Submit in Search Console | Submit the sitemap URL manually in GSC | GSC → Indexing → Sitemaps | On first submission, and again after splitting | Status shows “Success” |
| 4. Check the discovered count | Compare URLs discovered vs URLs submitted | GSC sitemap report | Once a week | A gap within 5% is normal |
| 5. Check for errors | Look for “Couldn’t fetch” or “URL not allowed” errors | GSC sitemap report | Once a week | Zero errors |
| 6. Speed up new pages manually | Use the URL Inspection tool to request indexing for important new pages | GSC URL Inspection tool | Each time you publish an important new page | Indexed within 1 to 3 days |
Check that your sitemap is correct: open https://yourdomain.com/sitemap.xml directly in a browser and you should see an XML list of pages. A 404 means the path is wrong or the server is misconfigured. If you get an HTML page instead (say, your WordPress theme’s 404 page), the sitemap wasn’t generated properly. Use Screaming Frog or an online XML sitemap validator to check for format errors.
and Technical SEO audit checklist relationship: the sitemap is item 2 in the crawl quadrant of the audit checklist. After every redesign, domain change, or large-scale content push, recheck whether the sitemap has been updated and whether it needs to be resubmitted in GSC.Site rebuilds and domain changes the sitemap must be regenerated and resubmitted, and every URL in the old sitemap must be 301-redirected to the new address.
FAQ
How long after submitting a sitemap does Google crawl it?
Do the priority and changefreq tags actually do anything?
How many URLs should a sitemap contain? Should every page go in?
When do you need a sitemap index file?
What should I do if the “Discovered URLs” count in the GSC sitemap report is far lower than the “Submitted URLs” count?
After publishing a new page, what can I do besides waiting for the sitemap to speed up indexing?
Final thoughts
The XML sitemap is the most overrated tool in technical SEO. It doesn’t improve rankings, pass authority, or decide whether pages get indexed. Its only job is to help Google find your pages faster. For a small or mid-sized site under 500 pages with solid internal linking, the sitemap’s marginal value is actually low. But it costs nothing, so you lose nothing by doing it, and you won’t die without it.
Three steps to put this into practice. This week, confirm your sitemap is reachable (visit /sitemap.xml in a browser and make sure it returns 200), and use Screaming Frog to check whether it contains thin pages that shouldn’t be there. Next week, declare the sitemap location at the end of robots.txt and submit it manually in GSC. After that, spend 5 minutes a week glancing at the GSC sitemap report to confirm the gap between discovered and submitted URLs is normal and errors are at zero.
One line worth remembering: a sitemap is an address book for Google, not a ranking bonus. Put the right pages in it, set lastmod correctly, and check the report once a week. Do those three things and you’re done. Don’t waste time on the priority tag.