A Preview Link Expiry Test for Unpublished Product Launches

Sharing a preview link lets a colleague or client see an unpublished product page. The risk is that the link outlives its purpose, gets forwarded, or leaks into a sitemap, a menu or a search index. This article proposes how to commission expiring preview links and an acceptance script that checks them. It is a conditional design proposal, and the examples are hypothetical.

What the preview should and should not be

A preview link should reach one page, for a limited time, and be revocable. It should not appear in navigation, internal search, listing pages or sitemaps, and it should be marked so that search engines are asked not to index it. Whether these are achievable depends on your platform, so treat each as a requirement to verify, not an assumption.

Commissioning checklist

Ask the builder to state, for each preview link:

Who can create one, and who is recorded as creating it
The default lifetime and the longest allowed
How to revoke one before expiry
What a visitor sees after expiry or revocation
Whether the link can reveal other unpublished pages
Whether the link works for a signed-in staff member differently from a visitor

The fourth item deserves care. An expired link should show a plain message that does not confirm what the page was, and it should not redirect to the live product listing, which could suggest the product exists.

Acceptance script

Run with a test product that is safe to expose.

Create a preview link with a short lifetime. Open it in a private window. The page should load.
Check the page head and response for a no-index signal, as your platform supports it.
Search the public site search for the product name. It should not appear.
Check category pages, menus and related product blocks. It should not appear.
Check the public sitemap. It should not appear.
Open the link after expiry. Expect the expiry message, with no product details.
Create a second link and revoke it manually. Open it. Expect the same message.
Create a link for page A and try altering the link to reach page B. Expect denial.
Publish the product. Confirm the old preview link still behaves as expired or revoked, as you decided, and that the public page works normally.

Branching choices

If previews are for internal staff only, a login requirement may be a better control than a secret link. If previews go to outside reviewers, links are more practical but need shorter lifetimes and a revocation habit. If a launch is delayed, decide whether to extend the existing link or issue a new one. Issuing a new one gives a clearer record.

Hypothetical worked example

A shop prepares a new kettle page. The owner creates a link with a two day lifetime for an outside photographer. In the script, steps 3 to 5 show the kettle absent from search, categories and sitemap. The photographer's link works the next day. On day three the link shows the expiry message. The owner then creates a second link for a copywriter and revokes it when feedback finishes, and the script confirms the revoked link behaves like the expired one. At publication, the old links stay dead while the public page loads.

Stop conditions

Stop the launch preparation if the unpublished page appears in any public listing, search or sitemap, if an expired link still shows product content, if a link can be altered to reach another page, or if nobody can say how to revoke a link quickly. Fix the cause and rerun the whole script, not only the failed step.

Acceptance checks

Consider the preview system acceptable when:

Every step of the script has a recorded pass for the current build.
Creation, expiry and revocation are traceable to a named person and time.
The expiry message reveals nothing about the page.
No test run leaves a link active afterwards.
The script is repeated after changes to templates, navigation or search configuration.

Treat any later change to those areas as a reason to rerun, since a new menu or search feature can reintroduce exposure without touching the preview feature.