Sharing a WordPress Brand Preview? Check Access Before Sending the Link

A brand review link often travels further than the design team expects. A stakeholder forwards it to a partner, someone pastes it into a shared document, and an unfinished WordPress site becomes a public reference. Before sending a preview, decide who may open it and whether its content is suitable for public access. A search indexing setting does not make a preview confidential.

Define the preview's audience before choosing a control

For a private client review, use an access control such as authenticated access or an approved network restriction. Test it in a fresh browser session without your administrator login. The test is whether an uninvited visitor can read the material, not whether the preview is missing from a search result.

If a demonstration is intentionally public, agree which content can be shown. Use approved sample records rather than a copy of live customer submissions, orders or account data. A review site should also make its status clear to a human visitor; otherwise a tester can mistake draft pricing or a sample form for the live service.

Keep access control and indexing control separate

For a publicly accessible preview that should stay out of Google Search, inspect the delivered HTML or HTTP headers for the intended noindex rule. Google's documentation on blocking indexing explains that Google must be able to crawl a resource to see that rule. Blocking the page in robots.txt while relying on a page-level noindex means the crawler may never read the instruction.

This does not mean a private preview should be opened to crawlers just to expose a tag. Keep confidential content behind access controls. Use indexing rules for the separate case of content that is allowed to be publicly reachable but should not appear in search. A canonical link is likewise not a password or an access boundary.

For a WordPress-focused handover, Guangsuan's preview-site indexing checklist, in Chinese, covers access restrictions, delivered indexing rules and checks after deployment. Use it to frame the checks with the person responsible for hosting, rather than assuming an editor's dashboard setting proves the output is correct.

Run the review journey as an outsider

1. Open the preview URL in a clean session. Confirm that the access challenge appears before private content.
2. After authorized login, open an interior page directly, not just the home page. Try the exact URLs included in the review invitation.
3. Check downloadable files separately. A protected page does not establish that every directly linked PDF or image has the same protection.
4. Test a sample form through its agreed test route. Confirm that the submission does not create a real order, contact a live customer or enter the production sales queue unexpectedly.
5. Record the preview address, access owner, permitted audience and review end date in the handover notes.

Use synthetic test details and clearly identify the test to the receiving team. The point is to verify routing and permissions without introducing a fake business lead into live reporting.

Make launch and preview closure separate tasks

At launch, check the public site for accidental preview restrictions and staging URLs. Compare its response headers, robots meta tag, canonical address and key links with the approved production settings. Do not copy an entire staging database over live content just to move a visual change; determine the intended deployment scope with the developer first.

Then revisit the preview itself. Keep it restricted if it remains a working environment, or retire it through the agreed hosting process. Removing a launch checklist item does not close an old preview address. Assign an owner to that final check so the next campaign does not inherit an abandoned public copy of the brand.