Product sitemaps contain some addresses repeatedly while published products appear to be absent. Looking only at the first file is insufficient when the sitemap is split into several parts. The reviewed report describes overlapping partitions and a suspected ordering issue involving equal timestamps. Its proposed code change is a user workaround, not evidence that every current Yoast store has the same defect. Q1
Establish the correct comparison set
The WooCommerce product count does not automatically equal the number of expected sitemap URLs. Drafts, individual variations, excluded content, redirects and different canonical addresses need to be classified appropriately. Yoast documents several legitimate reasons why an item may not appear as a separate entry. Q2
Start with a short list of specific product pages whose publication state and intended indexability you have checked. This turns a rough count discrepancy into an observable failure that someone else can investigate.
Check duplicates and omissions systematically
- Collect every child sitemap: Read the product sitemap addresses from the index and record the retrieval time. Do not silently compare files generated at different stages of an update.
- Count unique addresses: Record total entries, unique URLs and duplicated URLs separately. A large total can conceal omitted products when other addresses are repeated.
- Inspect one missing URL: Check publication, indexability, canonical address and the product page’s final response. Only classify it as a confirmed omission after it belongs to the expected set and is absent from every relevant child file.
- Compare partition boundaries: If duplicates and gaps cluster around the transition between files, have the ordering and retrieval query examined. Equal modification times are a testable hypothesis, not a cause established merely by the displayed output.
- Repeat against unchanged content: Capture the set again without editing products in between. Entries moving between files despite an unchanged collection are valuable evidence for the vendor or developer.
Choose the correction from the findings
Intentional exclusions do not require a pagination repair. For a confirmed query or ordering discrepancy, check applicable versions and official notices first. A targeted change on staging must preserve the complete URL set rather than merely improve the count on the first page. Avoid editing plugin files directly: updates can overwrite the change and complicate future comparisons.
Validate one previously missing page, one duplicated address and the aggregate unique set after the correction. Retain the before-and-after extracts so that improved output can be distinguished from an unrelated content change.
Frequently asked questions
Do matching counts prove completeness?
No. One omitted product and one duplicate can produce the same total. Compare the actual addresses.
Are missing variations always an error?
Not automatically. The relevant question is which independent, indexable product pages your store actually exposes.
Does a forum’s “resolved” label prove that a fix was released?
No. Check specific release notes and your installed behaviour. Closing a support thread is not equivalent to publishing a software correction.
Information for investigation
Provide versions, the sitemap index, a few confirmed duplicate URLs and a few expected missing URLs. A complete export containing customer data is unnecessary.
KAN KAI WORKS can compare sitemap partitions and the generation of the product URL list. Get help with this case.
Prepare a findings note
Summarise your observations for your enquiry. The note is created in your browser and is not saved or sent here. You can then copy it into the contact form.
Unknown is fine. Do not enter passwords, customer data or complete confidential logs.
Support with this issue
KAN KAI WORKS can compare sitemap partitions and the generation of the product URL list.
Sources and scope
Sources checked: 5 November 2026. The original incident has not been independently reproduced.
