A client says the site has 800 pages. The XML sitemap lists 1,240 URLs. My crawler finds 1,517, and Google Search Console reports 693 indexed pages.
Nobody has necessarily made a mistake. They are counting different things.
“How many pages does this website have?” sounds like a basic question until it lands in an SEO audit. I always ask which inventory we mean: what the site declares, what a crawler can reach, what can be indexed or what Google has indexed.
The four page counts
1. URLs declared in XML sitemaps
A sitemap is a list of URLs the site owner wants search engines to know about. A sitemap index can point to several child files for products, categories, posts, images or separate languages.
This is the easiest count to collect from the outside. Karma.Domains has a website page counter that finds the sitemap, follows nested files and totals the listed URLs. It also groups them by folder and can export the list to CSV.
For recurring inventory checks, the Karma.Domains Expired Domains API and MCP can run the counter inside a script or AI agent and send sitemap changes into an audit queue.
The number tells me the size of the declared inventory. It does not tell me whether those URLs return 200, contain useful content or appear in Google.
2. URLs a crawler can discover
A crawler such as Screaming Frog starts from one or more seeds and follows links. Its count depends on settings, robots.txt, JavaScript rendering, authentication, crawl depth and which URL patterns I include.
The crawl can find pages omitted from the sitemap, including old campaign URLs, faceted navigation, parameter variants and forgotten subdomains. It can also miss orphan URLs that have no internal links.
3. URLs that are technically indexable
An indexable URL usually returns a successful response, allows crawling, has no noindex directive and is not canonicalized to another address. That definition still needs judgment. A thin filter page can be technically indexable while serving no search purpose.
I calculate this number from a crawl after checking status codes, robots directives and canonicals. It is often lower than the raw crawl total because redirects, errors and duplicates fall out.
4. URLs indexed by Google
Search Console’s Page Indexing report shows how many known URLs Google indexed and how many it did not, with reasons. URL Inspection handles a specific page. These are the sources I use for a property I can access.
Google may know about URLs that are absent from the sitemap and current internal links. It may also exclude sitemap URLs because of duplication, quality, crawl issues or a different canonical choice.
What a sitemap page counter is good for
A fast content inventory
Before I crawl a site, the sitemap count gives me a rough idea of its declared size and structure. A 70-page service site calls for a different audit setup than an ecommerce store with separate product sitemaps and thousands of category URLs.
Folder groups are often more useful than the grand total. If /blog/ holds most of the URLs while /products/ has only a few dozen, I know where the publishing volume sits before opening a crawler.
A migration baseline
I export the old sitemap inventory before a migration and the new inventory after launch. A sudden drop from 3,200 declared URLs to 2,100 deserves an explanation, even if the project intentionally removed old content.
Then I compare the lists. Missing URLs need a relevant replacement, a deliberate 404 or 410, or a clear reason to remain outside the new sitemap. The count tells me that something changed. The URL diff tells me what changed.
A competitor size check
Public sitemaps can reveal how a competitor organizes its site. Separate XML files for locations, templates, products or editorial content show which page types exist and how much the company publishes.
I treat this as declared scale. A competitor can omit sections from its sitemap, leave dead URLs inside it or split files in a way that distorts quick comparisons. I sample the exported URLs before estimating content investment.
A publishing-cadence clue
When lastmod values are present and trustworthy, grouping them by month can show bursts of additions or updates. Some content management systems rewrite lastmod every time the sitemap regenerates, so the field needs a quick spot check against visible page dates.
A first pass on a domain
A current sitemap can show whether a domain hosts a working site, a small placeholder or a large content inventory. For acquisition research, the present-day count is only one clue. I use Karma.Domains to compare expired domains by archive history and backlink context because a new owner can replace a ten-year site with a five-page parking template overnight.
The comparisons that expose real SEO problems
Sitemap URLs versus crawlable URLs
If the crawler finds important URLs that are absent from the sitemap, I check whether the omission is intentional. Search engines can discover well-linked pages without a sitemap, though the mismatch can expose weak maintenance or a broken generator.
If sitemap URLs never appear in the crawl, they may be orphaned. That means the site declares them to search engines while users cannot reach them through internal links. Some utility pages can live this way, but commercial and editorial pages usually need a place in the site structure.
Sitemap URLs versus indexable URLs
A clean sitemap should mainly contain canonical, indexable URLs that return 200. Redirects, 404s, noindex pages and canonicalized duplicates make the file harder to trust and waste monitoring time.
I calculate a simple ratio: indexable sitemap URLs divided by total sitemap URLs. The ratio itself is not a ranking metric. It is a maintenance signal. A low number tells me to inspect the sitemap generator and the excluded groups.
Indexable URLs versus indexed URLs
This is where beginners often assume every gap is a problem. Google does not promise to index every technically eligible page. Duplicate product variants, weak location pages and near-empty tag archives may stay out for understandable reasons.
I focus on valuable page types. If 95 percent of core products are indexed while thousands of filter URLs are excluded, the site may be fine. If half of the revenue-driving categories are missing, the same overall total deserves urgent work.
Old count versus new count
A page-count trend helps after redesigns, CMS changes and large content projects. I store the sitemap total and folder totals on the same day each month or at major releases.
A change becomes useful when I can name the source. The team added 400 product pages. A plugin created 12,000 parameter URLs. A migration lost the Spanish sitemap. A bare number without the folder or page-type breakdown cannot tell those stories apart.
My ten-minute inventory workflow
For a quick external check, I use this sequence:
- Run the domain or direct sitemap URL through the page counter.
- Record the total, nested sitemap names and folder distribution.
- Export the URL list and sample pages from every large folder.
- Check a few URLs for status, canonical and robots directives.
- Look for page types that appear on the site but have no sitemap file.
- If I control the property, compare the inventory with Search Console’s Page Indexing report.
For a full audit, I add a crawl and join the data by normalized URL. That produces a working table with sitemap membership, crawl status, indexability and Google status instead of four totals sitting in separate tools.
Mistakes that make the number misleading
Calling sitemap URLs “all pages”
A sitemap is a declaration. Pages can exist outside it, and entries inside it can be broken. I label the number “URLs in sitemap” in every report.
Using site: search as an exact count
The site: operator is useful for spot checks and examples. Search result totals are estimates and can change between queries. Search Console is the better source for indexing totals on a site I own.
Counting URL variants as separate content
Parameters, trailing slashes, uppercase paths and print versions can inflate the raw count. I normalize carefully, then keep variants when they represent responses Google can actually crawl.
Trusting lastmod without testing it
The lastmod field should describe a meaningful page update. Some systems stamp every URL with the current time. I compare several values with visible edits before using them to describe publishing cadence.
Treating fewer pages as automatic improvement
Removing duplicate and empty pages can clean up a site. Removing useful long-tail landing pages can erase traffic. I judge the affected page types, internal links and search demand rather than celebrating a smaller total.
The number I put in the report
I rarely write “the website has 1,240 pages.” I write “the XML sitemaps declare 1,240 URLs,” then add the crawlable, indexable and indexed figures when I have them.
That wording may feel picky. It prevents the next person from comparing a sitemap count with Search Console and reporting a fake indexing crisis. In an SEO audit, the label matters as much as the number.
