A content item can exist in DynamoDB while the sitemap remains stale, CloudFront serves old HTML, an image path returns 404, or Search Console still sees the prior submitted count. A parity monitor compares the surfaces and then samples identity so a matching count does not hide the wrong URLs.
Use this for any headless, static, CDN-backed, or API-driven publishing system where content storage, page rendering, sitemap generation, image hosting, and search submission are separate steps.
Quick answer
Count published canonical items at the source, unique sitemap URLs, live 200 pages with matching canonicals, image objects, and Search Console submitted pages. Compare sets as well as totals, reject .html or parameter duplicates, and sample new, old, first, and last URLs after each batch. Alert on drift with the missing or extra identities attached.
What to check first
- Count unique published slugs at the source using a consistent status and time boundary.
- Parse the sitemap into canonical URL sets and reject duplicates, .html variants, parameters, and non-200 destinations.
- Fetch every new page and a rotating sample of older pages to verify title, canonical, schema, body, and indexability.
- Check hero and inline images for content type, size, cache status, and path identity.
- Compare Search Console sitemap submitted and discovered counts after download, allowing for documented processing delay.
Why this usually happens
- Content, HTML rendering, sitemap, images, and Search Console are updated by different services and caches.
- Equal totals can hide one missing URL and one unrelated extra URL.
- A clean page can return 200 while its canonical points home or its HTML contains only an app shell.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
source_published: 694
sitemap_unique_blog_urls: 694
live_200_canonical_pages: 694
html_variant_objects: 0
missing_from_sitemap: []
extra_in_sitemap: []
new_pages_verified: 12
new_images_verified: 24
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define the canonical identity and source status rules. | Count unique published slugs at the source using a consistent status and time boundary. | Source and sitemap sets match for every intended published post. |
| Collect source, sitemap, page, asset, and Search Console snapshots after each batch. | Parse the sitemap into canonical URL sets and reject duplicates, .html variants, parameters, and non-200 destinations. | Every new page returns 200 article HTML with self-canonical, schema, title, and indexable directives. |
| Calculate counts, duplicates, missing sets, extra sets, and sample contract failures. | Fetch every new page and a rotating sample of older pages to verify title, canonical, schema, body, and indexability. | Every referenced image returns the expected WebP content and useful size. |
| Invalidate only the stale layer and rerun the same snapshot. | Check hero and inline images for content type, size, cache status, and path identity. | Search Console shows the current sitemap submission without errors or warnings after processing. |
Decision rule
Call a batch discoverable only when every new canonical identity exists once at the source and sitemap, returns valid article HTML, loads its assets, and has no duplicate .html object. Treat Search Console count lag separately when submission and download evidence are healthy.
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 |
|---|
| Normal batch | Twelve new source items, pages, and sitemap URLs | Source and sitemap increase by twelve and every identity appears once |
| Stale sitemap cache | Source publishes while CDN serves prior sitemap | Monitor reports missing URL set and cache age rather than only count drift |
| Duplicate HTML variant | Clean URL plus accidental .html entry | Duplicate is rejected even if both return 200 |
| Broken image | Page exists with missing workflow asset | Page identity passes but asset verification fails the batch control |
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.
- Define the canonical identity and source status rules.
- Collect source, sitemap, page, asset, and Search Console snapshots after each batch.
- Calculate counts, duplicates, missing sets, extra sets, and sample contract failures.
- Invalidate only the stale layer and rerun the same snapshot.
- Store the verified report with publish time, cache evidence, and owner.
Production verification checklist
- Source and sitemap sets match for every intended published post.
- Every new page returns 200 article HTML with self-canonical, schema, title, and indexable directives.
- Every referenced image returns the expected WebP content and useful size.
- Search Console shows the current sitemap submission without errors or warnings after processing.
What to tell the client or owner
Share source and sitemap counts, set differences, page contract results, image results, duplicate variant count, CloudFront invalidations, Search Console submission and download times, exceptions, and owner.
Mistakes to avoid
- Do not compare totals without comparing URL identities.
- Do not treat a 200 app shell or homepage canonical as a valid article page.
- Do not create .html copies to work around a rendering issue.
- Do not label Search Console processing delay as a publishing failure without checking last download time.
Questions teams ask during testing
Should database and sitemap counts always match?
They should match the same intended published content scope. Static pages and excluded records need explicit count categories.
Must every page be fetched every day?
Verify every new page and rotate older samples. Full crawls can run on a slower schedule based on site size and risk.
Why check images for SEO?
Broken or repetitive assets reduce page usefulness, and missing image paths are a publishing defect even when HTML is valid.
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, audit a headless publishing pipeline.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references