Selecting a return policy page is only the first check. The selected page must be published, readable by shoppers and represented by the intended public URL in structured data. WooCommerce 11.3 beta adds a setting for this connection; it does not write a legally suitable policy for your business or guarantee a Google search feature.
Use staging for the October 28, 2026 beta workflow below. Have the business owner approve policy wording separately. This article tests technical delivery, not consumer-law compliance.
Start with the page shoppers can actually read
Open the existing returns page in a signed-out browser. Check the final URL after redirects, the heading, visible policy text and any country or product restrictions. A logged-in editor preview is not evidence that customers can read the page.
Record the page ID and permalink. If there are translated policies or several old policy drafts, identify which one the store intends to use before changing settings. Do not publish a draft merely because a selector lets you choose it.
In the beta, choose the policy through WooCommerce Settings, Advanced, Page setup. The upstream implementation links the selected published page through OnlineStore structured data. The policy page, rather than an assumed sitewide placement, is the first place to inspect.
Inspect one complete relationship
The relationship to verify is OnlineStore, then hasMerchantReturnPolicy, then merchantReturnLink. Compare the link with the intended policy permalink, including the correct production hostname. A staging URL in production markup is a release blocker.
Do not stop at finding the string merchantReturnLink somewhere in source. There can be multiple JSON-LD blocks from WooCommerce, an SEO plugin and a theme. Read each relevant object and identify its producer. A valid JSON parser can still accept contradictory store identities or obsolete policy URLs.
| Observation |
Next check |
| No policy markup |
Selected page, publication status, installed build |
| Old policy URL |
Origin output versus cached HTML |
| Two different policy URLs |
Competing schema producers and their settings |
| Correct markup, inaccessible page |
Redirects, access control and public response |
A reassignment test checks both the new page and the old page, so stale policy markup is not missed.
Reassign on staging to expose stale output
Create two clearly labeled test policy pages with no customer-facing claims. Select A, save, and inspect A and B. Then select B and inspect both again. The newly selected page should gain the core relationship; the former selection should not retain that core relationship.
Check the public cached response as well as an origin response available through your normal hosting tools. If the origin changed but the public copy did not, invalidate only the affected pages. Repeatedly saving settings can obscure whether the problem is cache or configuration.
Keep a homepage control in the test. The implementation's documented behavior places this core policy markup on the selected policy page. If the homepage also contains return-policy schema, determine whether an SEO integration intentionally emits it rather than assuming WooCommerce created a duplicate.
Validate without promising a rich result
Run the actual page through the validators appropriate to the markup you emit. A syntax pass confirms parseability, not eligibility for every Google presentation. Check for contradictions with merchant feeds and other structured data using your existing SEO process.
Store a redacted copy of the relevant JSON-LD, the selected page ID, final URL and test timestamp. Do not replace all schema globally to fix one obsolete link. That can remove unrelated product or organization information.
This setup is separate from refund API line-amount errors. A correct policy link neither creates a refund nor changes a payment provider's processing. For conflicting schema producers or a stale public page, get help tracing the WordPress output.
Sources checked October 28, 2026. Synthetic fixtures and diagrams illustrate the proposed checks; they are not claims of customer testing.