How to Publish /sku.md on Your Own Domain with WooCommerce
v1.0.0 features
A controlled WooCommerce publishing workflow from Store API evidence through WordPress routing, human review, atomic release, monitoring, and rollback.
Status: This article reflects the current v1.0.0-beta boundary. It reports a method and its evidence requirements, not unverified adoption, ranking, citation, recommendation, or sales outcomes.
WooCommerce runs inside WordPress, so the store owner usually has more control over routing than on a fully hosted platform. That control is useful only when generation, review, publication, monitoring, and rollback form one accountable workflow.
Current status and evidence threshold
The public WooCommerce proof of concept is not yet marked complete. The Store API and WordPress routing APIs provide the building blocks, but a WooCommerce support claim requires a public installation that another person can verify. Until that evidence exists, the steps below describe the intended PoC rather than an accomplished integration.
Map store evidence into a draft
Read products and variations from an authenticated, bounded store source. Map only fields whose meaning is clear: canonical product URL, title, approved description, dimensions, attributes, variation identifiers, and reviewed source links. Do not infer limitations from missing attributes or copy current stock and price into static knowledge.
Generation should produce a draft with provenance. For every output item, retain the WooCommerce field or editorial source that supplied it. If two sources disagree, route the item to review.
Register the public WordPress route
The plugin can register a rewrite rule or REST endpoint for /sku.md, then return UTF-8 Markdown with an accepted media type. Route ownership must be explicit, because themes, caching plugins, security middleware, or another plugin may already intercept the path.
Flush rewrite rules only when activation or configuration changes require it. Confirm the route as an unauthenticated visitor and record redirects, cache headers, and final bytes.
Put human review before publication
Editors should review the generated catalog and sampled product documents in a staging state. The review focuses on meaning: variant identity, unsupported claims, missing limitations, weak sources, and accidental live commerce fields. A parser can enforce syntax; it cannot decide whether a suitability claim is honest.
After validation, publish atomically so consumers never receive a half-written file. Keep the previously valid artifact available for rollback.
Update and invalidation loop
Trigger a new draft when approved product facts, identifiers, or source pages change. Inventory and price events should not regenerate SKU.md because those values are outside its boundary. Monitor the public route, validator result, source reachability, and age of the last approved document.
If validation fails, retain the last known good version and surface the failed draft to an editor. A removal should be deliberate: update the catalog first, then retire the product document.
PoC acceptance record
| Stage | Evidence to retain |
|---|---|
| Mapping | input fields, output claims, provenance |
| Review | approver, changes, unresolved questions |
| Publication | public URL, status, headers, content hash |
| Validation | tool version and result |
| Update | trigger and replacement timestamp |
| Rollback | restored version and reason |
Evidence threshold
Report this workflow as verified only after the plugin workflow is run on a public test store, route conflicts and cache behavior are documented, a change is propagated, and a deliberately invalid draft is prevented from replacing the valid resource. The result must be reproducible without access to the original developer’s machine.
Map WooCommerce data before generating Markdown
Begin with an explicit field map rather than serializing the entire product object. Product names, descriptions, attributes, categories, and variation identifiers may come from WooCommerce; approved guidance, limitations, compatibility, and sources may need editorial fields. Each mapping should state whether it applies to the product group or a specific variation. A missing merchant SKU cannot be repaired by silently substituting a database ID, GTIN, or slug.
The generator should produce a reviewable candidate, not publish every database value automatically. Strip private notes and administrative metadata. Exclude live price, stock quantity, coupons, shipping quotes, payment state, and orders. Resolve public source URLs on the final custom domain and reject drafts whose claims have no allowed source.
Own the root route through WordPress
A plugin can register a WordPress rewrite or REST route for /sku.md, but the public behavior is the contract. After changing rewrite rules, test from a clean installation and verify that the route survives permalink settings, caching plugins, localization plugins, security middleware, and a plain theme. The response should be public, deterministic, and free of an authentication or HTML fallback.
Record status, redirects, final URL, content type, cache policy, body hash, and generation revision. Validate the Catalog and every linked product knowledge document. A successful browser view is insufficient because browsers may render a fallback page that an automated consumer should reject.
Review, publish, update, and roll back
The plugin workflow should separate generation from approval. A product change creates a candidate diff. An editor reviews stable claims and sources, then publishes the entire affected set atomically. The previous revision remains available for rollback. Update triggers should be selective: changing inventory alone should not rewrite stable knowledge, while changing a material, compatibility attribute, or approved limitation should.
Evidence for a WooCommerce support claim requires a repeatable installation, public test store, route evidence, validator and graph results, update and rollback demonstrations, and documented conflicts with common cache or permalink settings. The claim is that this tested configuration works. Broader plugin support requires broader evidence.
Handle failure without serving a half-generated catalog
Generation can fail midway because a product contains invalid data, a source URL is unavailable, or a plugin hook throws. Build the new catalog in a staging location, validate it as a complete graph, and swap it into service only after every required document passes. If validation fails, keep serving the last approved revision and surface an administrative diagnostic. Never mix a new Catalog with old product documents or publish partial output under a successful status.
Cache invalidation belongs in the same transaction. Purge the canonical route and affected product documents after the swap, then request them through the public domain and compare their hashes with the approved artifacts. A scheduled health check can detect a theme, cache, or security update that later captures the route.
Define the plugin MVP by observable behavior
An MVP needs generation, an editorial diff, per-claim source visibility, validation, atomic publication, rollback, and a public verification command. It also needs access control for approval and escaping for every admin view. Bulk catalogs require request and generation budgets, but a consumer budget must not become a normative limit on how many products a merchant may publish.
Acceptance should use a fixture store with simple products, variations, missing optional identifiers, a deliberate conflict, and at least one invalid source. The report records which cases publish, block, or warn. This gives future plugin work a stable contract instead of a collection of screenshots.
Operational ownership completes the design. Someone must receive generation failures, approve content changes, review health checks, and decide when to roll back. The plugin should show the last successful public verification separately from the last database update. That distinction prevents an administrator from assuming that a recently edited product has already produced a valid public knowledge graph.