TrafficTriageSEO Tool Shows Fewer Pages Than Your Sitemap? Check This
By Ugur Saritepe · October 12, 2026
Your SEO tool shows fewer pages than your sitemap? The help pages say the cause is on your site. On 2026-10-11 it was on mine, and I mean the tool: TrafficTriage listed 165 pages for a site whose sitemap held 231, because the job that reads sitemaps had failed on every run for 33 days and reported nothing.
Where this came from
game-scout.app is my other site, and I track it in the Pages view of this product. It publishes a new curated list most days. On 2026-10-11 I opened the view and the count of lists looked low. This is what I typed to the assistant I work with:
it seems like list is not updated. Individual items are updated but it still shows 97 curated list for game-scout which has more.
The message has no number for "more". Nothing in the product had flagged anything. That is the whole detection story: a person remembering roughly how big their own site is.
What the two counts were
game-scout.app, 2026-10-11 tool's list live sitemap all pages 165 231 curated lists (/best/) 96 128 newest page in the tool's list 2026-09-07 (33 days old)
66 pages were missing from the tool, 32 of them curated lists, and every one had been published after 2026-09-07. The same thing had happened on this site: 47 pages listed against 72 in the sitemap. A third site of mine had never received a page list at all. All five sites on the instance were affected, which is the sample: five of five.
Why it happened: a string where a number was expected
Until 2026-09-08 the sitemap was read when someone opened the dashboard. That day the read moved into an hourly background job. The new job never read a sitemap once.
- The database returned the site id as text. The column is a 64-bit integer, and the database driver hands those back as the string
"6", not the number6. The code declared it a number, so the type checker was satisfied. - The lookup compared text to a number. The job built a table of sites keyed by the text id, then looked each site up by the numeric id. No site was found, and each one raised
no domain for site 6before any request left the server. - The error was caught and dropped. The job runs sites in a pool that catches a failing task so one bad site cannot stop the rest. The catch block was empty. Nothing was logged.
- The fallback looked like success. With no live sitemap, the job reused the copy stored on 2026-09-08 at 16:27 UTC, a few hours before the change shipped. It did that every hour for 33 days.
A dry run of the real job against production rows, with the write switched off, returned live: 0, fallback: 5. After the fix it returned live: 5, fallback: 0. All 1,277 tests passed before the fix as well as after it, because the test doubles used numeric ids. The fix is a cast in the query and one fewer conversion in the lookup, with a test that feeds text ids.
What stayed green the whole time
Nothing in the product looked broken, and that is why it lasted a month.
- Every row had a recent crawl date. Re-checking known pages is a different job from finding new ones, and that job was fine. The row I pulled on 2026-10-12 showed a crawl on 2026-10-10.
- Changes kept arriving. Edits to the 165 known pages were detected and dated as usual.
- Search Console columns were filled. Clicks and impressions come from Google by URL, so known pages had fresh numbers.
- No error, anywhere. No failed job, no warning in the view, no log line.
What the help pages say, and what they leave out
I read the pages that rank for this question on 2026-10-12. The vendor help pages list causes on your side only. Ahrefs gives two: you entered the www version of a non-www site, or the site needs JavaScript to show its links. Semrush gives four: no internal links on the homepage, a robots.txt or noindex block, a homepage over its size limit, and the crawl source setting. Those are real and you should rule them out first. Neither page mentions the tool holding an old page list, and neither tells you to hold its count against your sitemap. One agency article does say to compare the crawled count with the size of the site, using a made-up example.
So there are two families, and they need different checks.
what you see family tool found 5 pages of 200, from day one it cannot reach them (your side) tool has 165 of 231, and had all of them once its page list stopped updating missing pages are all newer than one date its page list stopped updating missing pages are scattered across all ages it cannot reach them (your side)
After the fix
The fix merged on 2026-10-11 at 18:46 UTC. I pulled the list again the next morning.
game-scout.app, urlContains "/best/", then uncrawled only
tracked: 232 under /best/: 128 never crawled: 66 (all trackedSince 2026-10-11)
The list went from 165 to 232 and the curated lists from 96 to 128 on the first run after the deploy. This site went from 47 to 72. The 66 new rows were still waiting for their first crawl eight hours later, so their link counts and health checks are empty for now. And the month is not recoverable: pages published between 2026-09-08 and 2026-10-11 have no change history for those weeks, because nothing was watching them.
Google holds a dated copy too. The same morning Search Console reported the game-scout.app sitemap as last downloaded on 2026-10-04, with 212 URLs. The difference is that Google shows you the date.
What we have not done
We have not made the pool log the errors it catches. The pull request says so in its own "not in this PR" line, and the empty catch block is still on the main branch today. We have not added the check that would have caught this in an hour: tracked count against live sitemap count, with an alert when they drift. Until both exist, the next failure of this kind will be found the same way this one was, by someone noticing. This is also not the first time this view has shown a failure as missing data. In September an expired Search Console permission blanked that column on all 165 rows while the data itself was intact.
How to check your own tool in five minutes
- Count your sitemap. Open
yoursite.com/sitemap.xmland search the page for<loc>. The match count is your URL count. If the file lists other sitemaps, count each one. - Count the tool. Find the total it shows for pages crawled or tracked. Good: within a few of the sitemap, with the difference explained by pages you published today. Bad: a gap that grows every week.
- Search for last week's page. Pick one URL you published in the last seven days and look for it in the tool. Absent means the list is stale, whatever the dates on other rows say.
- Find the newest page it has. Sort by first seen or date added. Good: this week. Bad: every row was added before one date. That date is when discovery stopped.
- Then check your side. If the missing pages are spread across all ages, work through the help-page causes: host version, JavaScript links, robots.txt, crawl limits. Our free triage report checks the sitemap and robots.txt from the URL alone.
The same count applies to Google: the Sitemaps report in Search Console shows discovered URLs and the last read date, and a sitemap that reads Success with 0 discovered pages is the extreme case. What this view catches when it is working is in is website change monitoring worth it, and the rest of these measured reads are in the AI-assistant SEO series.
FAQ
Why does my SEO tool show fewer pages than my sitemap?
Either the tool could not reach the pages, or it is working from an old copy of your page list. The help pages cover the first kind: a www mismatch, links hidden in JavaScript, a robots.txt block, a crawl limit. The second kind produces no error. On my own tool the sitemap reader failed on every hourly run for 33 days, the list stayed at 165 pages while the sitemap grew to 231, and every row kept updating.
How do I check whether a tool has all my pages?
Count the URLs in your live sitemap, count the pages the tool lists, and compare the two numbers on the same day. Then name one page you published in the last week and search for it in the tool. If it is absent, find the date of the newest page the tool does have. That date is when its page list stopped updating.
Does a recent last-crawled date mean the tool is up to date?
No. It means the pages the tool already knows about were fetched recently. Finding new pages is usually a separate job from re-checking known ones. On game-scout.app every one of the 165 listed pages showed a crawl from the last day or two while 66 newer pages were missing from the list entirely.
Does Google have the same problem with my sitemap?
Google also works from a dated copy. On 2026-10-12 Search Console reported the game-scout.app sitemap as last downloaded on 2026-10-04 with 212 URLs, while the live file held about 230. That is normal and it catches up on the next download. The Sitemaps report shows the last read date, so you can see how old the copy is.
The Pages view is the thing that was wrong for 33 days, and it is fixed. Create a free account, add your site, and it lists every page in your sitemap with its last crawl, its last real edit, its internal links and, with Search Console connected, its clicks against the previous fortnight. It shows the tracked total and a count per URL section above the table, so you can hold both against your sitemap. It does not yet warn you when the two drift apart. That check is not built.
In your AI assistant
Ask your AI about your own site
TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.