Sitemap Priorities Explained: What priority and changefreq Actually Do

Google has stated that it generally ignores priority in an XML sitemap, so a 1.0 on every URL does not change rankings. changefreq is a hint, and a false daily on a page that rarely changes gives crawlers a reason to discount the file. What the sitemap can do is list URLs for discovery, with an honest lastmod. Include every indexable tool page, such as JSON Formatter, and keep each sitemap under 50,000 URLs and 50 MB uncompressed. Edge cases, platform limits, and regulatory rules vary. Test on a sample file and keep the original source archived.

A sitemap that marks every URL priority 1.0 and changefreq daily is describing a site that does not exist. A PDF compress tool unchanged for four months, and a blog with one post a week, are not both daily updates. Crawlers that see that mismatch learn to ignore the file.

XML sitemaps help search engines discover URLs and come back to them. They are not a ranking control. Priority and changefreq sound like orders. Google treats them as weak hints at best. Completeness, an accurate lastmod, a sensible split of files, and internal links that match the sitemap are what hold up.

What an XML sitemap does

A sitemap lists URLs you want indexed, plus optional metadata:

<url>
  <loc>https://vertexssolutions.com/pdf/compress-pdf</loc>
  <lastmod>2026-09-15</lastmod>
  <changefreq>monthly</changefreq>
  <priority>0.8</priority>
</url>

Submit it through:

• a robots.txt line: Sitemap: https://vertexssolutions.com/sitemap.xml
• the Google Search Console sitemap report
• Bing Webmaster Tools

A sitemap supplements crawling. Internal links remain the path people and crawlers follow from one page to the next. See content clusters.

Priority is relative, and mostly ignored

priority accepts 0.0 to 1.0, relative to other URLs on your site only. It does not compare your homepage with a competitor's homepage.

Google's position is that priority is typically ignored for ranking and for crawl order.

If you still set it, for another engine or for your own bookkeeping:

| URL type | Suggested relative priority | |----------|----------------------------| | Homepage | 1.0 | | Category hubs (/pdf, /image) | 0.9 | | Flagship tools | 0.8 | | Blog index | 0.7 | | Individual blog posts | 0.6 | | Legal (privacy, terms) | 0.3 |

Setting every URL to 1.0 wipes out the scale.

Tool pages rise because of internal links from posts people actually open, because of engagement, and because of links from other sites.

changefreq should match the page

changefreq hints how often the content changes: always, hourly, daily, weekly, monthly, yearly, never.

In practice:

• Google may use it loosely when it schedules a recrawl
• daily on a static page spends credibility you wanted for real updates
• Leaving changefreq out is fine

A realistic map for this site:

• /blog index: weekly, when new posts go up
• A new blog post: monthly after the first week
• Tool pages: monthly, unless a feature ships
• /privacy and /terms: yearly
• Homepage: weekly if the modules on it rotate

Pair that with an honest lastmod.

lastmod is the field worth getting right

lastmod should mark a real content or metadata change, not a deploy timestamp on a page that did not change.

Update lastmod when:

• Tool UI or copy changes
• A blog post gets a substantive edit
• A tool page gains a new FAQ section

Leave lastmod alone when:

• A site-wide CSS tweak would stamp every URL
• The build writes "now" onto every page

Google's Gary Illyes has emphasized that an accurate lastmod helps recrawl decisions. Fake freshness trains crawlers to deprioritize your signals.

For MDX posts, use the file mtime or the frontmatter date or updated field. Use build time only when the content changed.

Structure for a site with several sections

This site spans /pdf, /image, /text, /calculators, /developer, and /blog.

Option A, one sitemap, is fine under about 500 URLs:

sitemap.xml
  ├── /
  ├── /pdf/*
  ├── /image/*
  ├── /blog/*
  └── ...

Option B, a sitemap index, scales:

sitemap-index.xml
  ├── sitemap-tools-pdf.xml
  ├── sitemap-tools-image.xml
  ├── sitemap-blog.xml
  └── sitemap-pages.xml

An index makes it easier to see which section is filling the "Discovered, not indexed" bucket in Search Console.

What to include and what to leave out

Include:

• Every indexable tool page
• Blog posts and category indexes
• About and contact, if they are indexable
• Category landing pages

Exclude:

• noindex URLs
• Admin and API routes (/api/*)
• Internal search results (/search?q=)
• Parameterized duplicates that have no canonical
• Paginated duplicates whose canonical points elsewhere

Duplicate content on tool pages: the sitemap should list canonical URLs only.

robots.txt

User-agent: *
Allow: /

Sitemap: https://vertexssolutions.com/sitemap.xml

Do not block a URL you also list in the sitemap. Do not list a URL that robots.txt blocks. The two files would contradict each other.

Sitemap and internal links

| Mechanism | Primary role | |-----------|--------------| | Internal links | Topical connections, paths for people, and strong crawl discovery | | Sitemap | A backup discovery path, especially for deep or new URLs | | Priority and changefreq | Minor hints, often ignored |

A new post linked from the blog index and from a pillar page gets crawled quickly without priority 1.0. An orphan post that appears only in the sitemap can still lag.

Crawl budget

Sites with 100,000 or more URLs worry about crawl budget. A site at this scale rarely needs aggressive budget tuning. Still:

• Drop soft-404 and thin URLs from the sitemap
• Fix redirect chains before you list the target
• Use lastmod to mark content that actually changed

Page speed and PDF embeds: a slow page wastes crawl time if a bot keeps fetching heavy assets.

Image and news sitemaps

An image sitemap is optional. It can list image URLs, titles, and captions when you care about image search. It sits alongside alt text that helps SEO on the page.

A news sitemap is for Google News publishers. A typical tool blog does not need one.

RSS and the sitemap

/feed.xml announces new posts to subscribers and to some aggregators. The sitemap and the feed serve different readers. Keep both for a blog.

When a post goes out:

1. Publish the MDX
2. The build regenerates the sitemap lastmod
3. The feed picks up the item
4. Request indexing in Search Console for posts you want crawled soon (optional)

Search Console

The sitemap report shows:

• Submitted versus indexed counts
• Errors such as an invalid URL or a blocked URL
• "Couldn't fetch", which points at the server or TLS

How to read a gap:

• Submitted is higher than indexed: quality, duplicates, or a crawl delay
• Indexed is higher than submitted: Google found URLs from links, which is normal

Cross-check the Pages report for "Crawled, currently not indexed."

Mistakes

1. Every priority set to 1.0, which erases the scale
2. daily on a static tool page, which costs credibility
3. Listing noindex pages, which contradicts the page
4. HTTP URLs on an HTTPS site
5. Inconsistent trailing slashes, which create duplicate loc entries
6. Mixing www and non-www. Pick one host and use it in the sitemap

Generating the file in Next.js

app/sitemap.ts can build the list from the tool registry and the blog MDX slugs, the same source as the published tools config and the structured data.

Pull slugs from:

• config/published-tools.ts
• content/blog/*.mdx frontmatter
• A static routes array

Set lastmod from git history or from the content date field.

Related articles

• Internal Linking and Content Clusters: the main discovery path
• Duplicate Content on Tool Pages: canonical URLs in the sitemap
• Meta Descriptions That Get Clicks: metadata next to the sitemap
• Core Web Vitals and Images: crawl time on heavy pages

Limitations

Edge cases, platform limits, and regulatory rules can vary. Test on a sample file first and keep the original source archived. Priority does not change a ranking. An orphan URL listed only in the sitemap can still lag behind one linked from the blog index and a pillar page.

Accurate lastmod, a changefreq that matches the page, and a complete list of indexable URLs are the sitemap work. Internal links and the content itself are what crawlers use when they decide what to fetch next.