A public sitemap can contain more canonical URLs than Search Console currently reports as discovered. The gap may be a new publishing cohort that Google has not read into the report yet, removed URLs still reflected in an older count, duplicates, parse errors, redirects, inaccessible HTML, or a sitemap that has not been fetched since the change.
Use this for technical SEO, content operations, developers, CDN teams, and site owners publishing through a CMS, database, static build, prerender, or custom sitemap generator.
Quick answer
Count unique canonical URLs in the public sitemap and save its ETag, Last-Modified, fetch time, and hash. Record Search Console submitted date, last read, status, and discovered count. Build sets for new publishes, removals, redirects, duplicates, non-200 pages, canonical mismatches, blocked pages, and clean versus alternate URL shapes. If the sitemap is successful and was read recently, give the new cohort a documented review window instead of resubmitting repeatedly.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Successful recent read | New URLs published after report count | Observe until documented review |
| Sitemap could not fetch | Current endpoint failure | Fix access and resubmit after repair |
| Count matches, identities differ | Missing and extra URLs offset | Repair generator or source parity |
| Alternate .html paths | Duplicate URL shape appears | Remove duplicate and keep one canonical clean URL |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze source, sitemap, page, and Search Console counts with timestamps and URL sets. | Fetch the public sitemap as Googlebot and record status, content type, ETag, Last-Modified, hash, total URLs, unique URLs, and duplicate URL shapes. | Source and sitemap unique URL sets reconcile after intended non-blog pages are accounted for. |
| Repair any source-to-sitemap, canonical, rendering, robots, duplicate, or HTTP defect. | Record Search Console sitemap URL, submitted date, last read, status, discovered pages, errors, warnings, and property scope. | Every new clean URL returns one canonical article with valid metadata and assets. |
| Keep the successful sitemap registered and avoid redundant submission during normal processing lag. | Compare DynamoDB or CMS items, sitemap identities, live clean pages, canonicals, robots, noindex, redirects, images, and prerendered article HTML. | No duplicate .html or alternate host paths compete in the sitemap. |
| Add contextual incoming links so new pages are discoverable outside the sitemap. | Classify the delta into new cohort, removed cohort, duplicate, alternate path, fetch lag, parse issue, inaccessible page, or unknown. | Search Console shows a successful sitemap read and the cohort has a scheduled follow-up. |
What to check first
- Fetch the public sitemap as Googlebot and record status, content type, ETag, Last-Modified, hash, total URLs, unique URLs, and duplicate URL shapes.
- Record Search Console sitemap URL, submitted date, last read, status, discovered pages, errors, warnings, and property scope.
- Compare DynamoDB or CMS items, sitemap identities, live clean pages, canonicals, robots, noindex, redirects, images, and prerendered article HTML.
- Classify the delta into new cohort, removed cohort, duplicate, alternate path, fetch lag, parse issue, inaccessible page, or unknown.
- Set a next review date based on the last successful read and publishing time, then inspect a representative new URL live.
Field notes
- Store set differences, not only counts.
- Use the root canonical sitemap and avoid duplicate clean and .html copies.
- Record the last successful read before deciding that Google has ignored a new cohort.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
surface,count,observed_at,last_read,status,new_cohort,missing,extra,decision
DynamoDB,793,2026-08-18T13:00Z,n/a,current,0,0,0,source
Public sitemap,822,2026-08-18T13:00Z,n/a,200,0,0,0,valid
Search Console,810,2026-08-17T00:00Z,2026-08-17,Success,12,0,0,observe
Why this usually happens
- Search Console reports are not a real-time mirror of a sitemap file.
- Equal totals can hide different URL identities.
- The content source, sitemap, prerender, CDN, and Search Console update on separate clocks.
- Repeated submission cannot repair missing canonical HTML or weak internal discovery.
Decision rule
Treat the gap as normal lag only when every new canonical identity exists once in the source and sitemap, returns valid article HTML, has an incoming link, and the sitemap was fetched successfully. Otherwise repair the specific parity defect.
Production verification checklist
- Source and sitemap unique URL sets reconcile after intended non-blog pages are accounted for.
- Every new clean URL returns one canonical article with valid metadata and assets.
- No duplicate .html or alternate host paths compete in the sitemap.
- Search Console shows a successful sitemap read and the cohort has a scheduled follow-up.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze source, sitemap, page, and Search Console counts with timestamps and URL sets.
- Repair any source-to-sitemap, canonical, rendering, robots, duplicate, or HTTP defect.
- Keep the successful sitemap registered and avoid redundant submission during normal processing lag.
- Add contextual incoming links so new pages are discoverable outside the sitemap.
- Review the same publish cohort after the documented processing window.
Mistakes to avoid
- Changing production before preserving exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, providers, caches, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, reconcile a WordPress sitemap.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references