Sharing a WordPress draft without creating an account

Sharing a WordPress draft without creating an account is useful whenever someone needs to review unpublished content but does not actually need access to WordPress itself. Clients, proofreaders, legal reviewers, managers and external collaborators may need to read a page before publication without becoming users of the website.

WordPress normally protects drafts from logged-out visitors. That is the correct default, but it creates an awkward gap when an external reviewer needs to see the real page rather than a screenshot or copied document.

Creating a temporary WordPress account can solve the problem, but it also creates credentials, permissions and cleanup work for someone whose only task may be reading one draft.

A better approach is often to create a controlled preview link that temporarily exposes only the content being reviewed while leaving the WordPress account system untouched.

This guide explains the available approaches, why WordPress drafts are normally private, how secure preview links work, when passwords and expiration limits make sense, why unpublished previews should remain out of search engines and how to build a clean review workflow without handing out unnecessary WordPress accounts.

Why WordPress drafts are not public by default

WordPress uses post statuses to determine how content should behave.

Common statuses include:

• Draft;
• Pending Review;
• Scheduled;
• Private;
• Published.

The official WordPress Post Status documentation explains how these states fit into the publishing workflow and how WordPress distinguishes drafts, pending content, future posts, private content and published posts.

The current editor also exposes these states through the page and post settings interface, described in the official Page/Post Settings Sidebar documentation.

A published post is intended to be publicly accessible.

A draft is not.

That means a visitor who simply knows the expected permalink cannot normally open an unpublished draft unless they have the necessary WordPress permissions.

The normal WordPress preview assumes you are logged in

When an editor clicks Preview inside WordPress, WordPress generates a dedicated preview URL for that content.

Internally, WordPress provides the get_preview_post_link() function for retrieving the URL used to preview a post.

WordPress also exposes the preview_post_link filter, allowing themes and plugins to modify that URL when necessary.

The normal editor preview works perfectly for:

• authors;
• editors;
• administrators;
• other logged-in users with sufficient permissions.

It does not automatically solve the external-review problem.

If you copy your normal editor preview URL and send it to a client who is not logged into the site, they generally cannot use it as though it were a normal public page.

The preview belongs to WordPress’s authenticated editing workflow rather than being designed as a general-purpose guest-sharing system.

The obvious solution is creating an account

You could create a WordPress user for every reviewer.

For example:

Client:
client@example.com

Role:
Subscriber

The reviewer logs in, receives whatever permissions you configure and can then access content through an authenticated workflow.

WordPress accounts are associated with roles and capabilities that determine what each user is allowed to see and do. The official Roles and Capabilities documentation explains this permission system.

This approach is valid when the person genuinely needs ongoing WordPress access.

It becomes cumbersome when the actual requirement is:

Please read this page and tell me whether you approve it.

Every account creates administrative overhead

A temporary reviewer account introduces several things that now need to be managed:

• username;
• password;
• password reset;
• role assignment;
• permissions;
• login access;
• future account cleanup;
• security responsibility.

If the reviewer later needs another draft, the account may remain useful.

If they were only supposed to inspect one article, the account may remain in the Users table for years because nobody remembers why it exists.

WordPress’s own developer guidance recommends applying the principle of least privilege and giving users only the permissions required for their work. See the official WordPress Users documentation for that guidance.

For a deeper explanation of what those accounts can actually do, see WordPress user roles and capabilities, explained.

Do not create administrator accounts for reviewers

This deserves explicit mention because it happens far more often than it should.

A client who needs to review one draft does not need:

Administrator

permissions.

An Administrator can potentially:

• install plugins;
• change themes;
• manage users;
• modify settings;
• edit large parts of the site;
• access sensitive administrative information.

Giving someone administrative access merely because it makes previewing a page easier is an enormous permission increase for a tiny workflow problem.

Capability checks are the mechanism WordPress uses to protect privileged actions, and developers are expected to check permissions before exposing sensitive functionality. The official User Roles and Capabilities API documentation covers this security model.

Another common solution is sending screenshots

Screenshots avoid creating an account, but they introduce different problems.

A screenshot cannot properly represent:

• responsive behavior;
• hover states;
• links;
• forms;
• animations;
• scroll behavior;
• interactive blocks;
• actual browser typography;
• dynamic content.

It also becomes stale immediately after you change the page.

The reviewer may be commenting on:

homepage-v4-final-2.png

while the developer is already working on an entirely different version.

Copying the content into a document has the same problem

Another option is copying the text into Google Docs, Word or another review tool.

This can work well for pure copy editing.

It works less well when the reviewer needs to evaluate:

• layout;
• hierarchy;
• images;
• responsive presentation;
• buttons;
• page flow;
• actual WordPress rendering.

The document and the website become two separate versions that need to remain synchronized.

A preview link solves a narrower problem

A shareable preview link lets someone view unpublished WordPress content without becoming a WordPress user.

The general idea is:

Draft inside WordPress
        ↓
Generate protected preview link
        ↓
Send link to reviewer
        ↓
Reviewer sees rendered page
        ↓
Draft remains unpublished

The reviewer gets access to the content rather than access to WordPress.

That is an important distinction.

Use Preview Links in TheOneWP

TheOneWP Preview Links creates temporary shareable URLs for unpublished WordPress content without requiring the recipient to have a user account.

The module supports preview links for:

• draft posts;
• pending posts;
• scheduled posts;
• private posts.

These states correspond to WordPress’s normal content workflow. The official WordPress Posts Screen documentation shows how posts can be filtered by Published, Scheduled, Pending Review, Draft and Private states in the administration interface.

A published page no longer needs a special preview link because its public permalink becomes the correct address to share.

A preview URL should reveal as little as necessary

A good preview system should not encode unnecessary content information directly into the URL.

For example, a token-based URL might conceptually look like:

https://example.com/?preview_token=
f83c1d49b26147d690c329af11d07c71

The token grants access to one specific preview without requiring the recipient to know:

• the WordPress post ID;
• an admin URL;
• the author’s username;
• internal editor paths.

TheOneWP Preview Links uses a random token in the shared URL rather than exposing the post title or ID in the access mechanism.

A preview token and a WordPress nonce are not necessarily the same thing

WordPress also has a built-in nonce system used to protect actions against certain request-forgery scenarios.

The official WordPress Nonces documentation explains that WordPress nonces are tied to actions, users, sessions and limited time windows.

Importantly, WordPress explicitly warns that nonces should not be treated as authentication, authorization or general access control.

A long-lived anonymous preview token therefore needs its own access model rather than simply assuming that any URL token automatically provides security.

A hard-to-guess URL is useful, but it is not the same as a password

A sufficiently random token makes accidental discovery difficult.

However, anyone who receives the complete URL can potentially forward it.

For ordinary client review, possession of the link may be sufficient.

For more sensitive material, add another layer.

Add a password when the content deserves extra protection

A preview system can combine possession of the link with a password.

The workflow becomes:

Reviewer receives preview URL
        ↓
Reviewer opens URL
        ↓
Password requested
        ↓
Correct password supplied
        ↓
Draft rendered

This is useful for content such as:

• unreleased announcements;
• pricing changes;
• legal drafts;
• confidential client work;
• future product pages;
• sensitive editorial material.

Preview Links supports password protection independently for each generated link.

Create separate links for separate reviewers

Sharing one universal preview link with everyone makes later access management difficult.

A better structure is:

Client:
Preview link A

Proofreader:
Preview link B

Legal:
Preview link C

Each link can then have its own:

• label;
• expiration;
• password;
• view limit;
• revocation state.

If the legal review ends, you can revoke the legal link without breaking access for the client.

Label preview links clearly

If several links exist for one draft, names such as:

Link 1
Link 2
Link 3

become useless almost immediately.

Use labels such as:

Client review
Legal approval
External proofreader
Marketing team

This makes later management considerably easier.

Use an expiration date

A preview link often exists for a temporary reason.

For example:

Review period:
August 25–28

Preview access:
Expires August 29

Once the review is over, there is little reason for the temporary access path to remain valid indefinitely.

A sensible expiration policy reduces forgotten links and limits the lifespan of accidentally forwarded URLs.

Never-expiring links should be deliberate

There are situations where a long-lived link is useful.

For example, an external editor may need recurring access to a scheduled article during a long approval cycle.

But “never expires” should be a conscious decision rather than the default result of not thinking about cleanup.

Temporary access that has no expiration has an impressive ability to stop being temporary.

View limits can provide another control

A preview link can also be restricted by the number of times it may be opened.

For example:

Maximum views:
5

This may be useful when:

• one or two people should inspect the content;
• the material is sensitive;
• you want accidental redistribution to have a limited lifespan.

TheOneWP allows a maximum view count to be configured independently from the password and expiration settings.

Do not make view limits too restrictive

A reviewer may legitimately open the same page several times.

They might:

• open it on desktop;
• check it on mobile;
• return after a meeting;
• open the link from an email again;
• compare two revisions.

A single-use link sounds wonderfully secure until the client opens it once, closes the browser and immediately asks why the link is broken.

Link preview bots complicate view counting

Messaging platforms and email clients sometimes request a URL automatically to generate a preview card.

This may happen before the recipient actually clicks the link.

A naive view-limited system could interpret that automated request as the only allowed view.

TheOneWP Preview Links ignores HEAD requests when recording views, preventing common link-preview checks from consuming the view allowance before the actual reviewer opens the page.

Unpublished preview pages should remain out of search engines

A page can be reachable without being intended for search.

A temporary client preview might contain:

• unfinished copy;
• draft pricing;
• placeholder images;
• unapproved claims;
• future product information.

Search engines should not treat that review URL as an ordinary public landing page.

Google supports noindex through both HTML robots meta directives and the HTTP X-Robots-Tag header. Its official robots meta tag and X-Robots-Tag documentation explains how these directives prevent eligible URLs from remaining indexed.

Why noindex matters for unpublished content covers the WordPress side of this distinction in detail.

Preview Links automatically blocks indexing

Preview Links sends indexing restrictions with preview responses so the temporary version is not intended to enter search results.

The implementation uses both WordPress robots handling and an HTTP:

X-Robots-Tag: noindex, nofollow

header for the preview response.

This is important because creating a shareable URL should not quietly turn unfinished content into an SEO landing page.

Noindex is not access control

Even with noindex, a preview remains accessible to someone who has valid access to the link.

noindex means:

Do not include this page in search results.

It does not mean:

Do not let unauthorized people read this content.

If confidentiality matters, combine the preview token with an expiration, password or other appropriate protection.

For the broader difference, see Robots.txt vs real access control.

Preview links are not appropriate for highly confidential secrets

A WordPress preview system is useful for ordinary editorial and client-review workflows.

It should not become a substitute for a proper secure document system when the material includes:

• credentials;
• financial secrets;
• private customer data;
• regulated documents;
• highly confidential internal records.

Choose the access mechanism according to the consequences of unauthorized disclosure.

What happens when the draft is published?

A review link should not become a mysterious dead URL the moment the content goes live.

Suppose the reviewer originally receives:

https://example.com/?preview_token=abc123

and the article is eventually published at:

https://example.com/guides/security/

Preview Links redirects an existing preview link to the real published permalink after publication.

WordPress provides the transition_post_status hook for code that needs to react when a post moves between workflow states such as Draft and Published.

The temporary route can therefore transition naturally into the final public route instead of leaving the recipient with a stale preview.

Why redirecting after publication is useful

Clients and stakeholders often reopen old emails.

Without this behavior, they might revisit an old preview URL months later and encounter:

• an expired error;
• a broken page;
• an obsolete version;
• an unnecessary duplicate.

Redirecting to the published address makes the final permalink the authoritative destination once publication occurs.

Comments should normally be disabled on previews

A preview link exists to let someone inspect unpublished content.

It is not necessarily intended to behave like a fully published post.

Allowing comments on the temporary preview could create a strange state where interactions are attached to content that technically remains unpublished.

TheOneWP therefore disables comments and pings while content is being served through a preview link.

Use your real feedback channel instead of preview comments

Client feedback should normally live somewhere designed to track decisions.

Examples include:

• project management software;
• a shared document;
• a dedicated email thread;
• a ticket;
• a review platform.

This keeps feedback separate from public WordPress comments and makes the review process easier to audit.

For the complete process, see Setting up a client review workflow in WordPress.

Use staging when the reviewer needs to inspect the whole site

A preview link is ideal for one post or page.

It is less appropriate when the client needs to evaluate:

• an entire redesign;
• navigation;
• several interconnected pages;
• checkout;
• membership flows;
• global headers and footers;
• responsive behavior across templates.

In those situations, use a staging environment instead.

WordPress staging site best practices explains how to keep a test environment separate, protected and safe to review.

Use Site Password Protection for whole-site client review

If the client needs to browse an entire pre-launch website, protecting the frontend behind one shared gate can be simpler than issuing preview access for dozens of individual pages.

TheOneWP Site Password Protection can protect the full frontend with a shared password.

The distinction is useful:

Preview Links
→ individual unpublished content

Site Password Protection
→ entire review environment

Do not create one shared WordPress login for several reviewers

If several external reviewers genuinely need WordPress access, create separate accounts rather than distributing one username and password.

Shared accounts make it difficult to determine:

• who logged in;
• who changed something;
• who still has the password;
• when access should be revoked.

A preview link avoids this problem entirely when the reviewers only need read access.

Preview links are better than guest accounts for one-off reviews

Compare the two approaches.

Temporary WordPress account

Create user
Assign role
Send credentials
Reviewer logs in
Reviewer views content
Review ends
Remember to delete account

Preview link

Generate link
Send link
Reviewer views content
Review ends
Link expires or is revoked

The second model gives the reviewer only the capability they actually needed: viewing the draft.

Preview links are not user identities

A preview token represents access to content, not a WordPress user.

That means the recipient does not receive:

• a user profile;
• a role;
• wp-admin access;
• editor capabilities;
• site-wide authentication.

This makes preview links a poor fit when you need the reviewer to perform actions that require a real identity inside WordPress.

Use an account when the reviewer needs to edit

If the client needs to:

• modify text directly;
• upload images;
• submit posts for review;
• approve editorial content inside WordPress;
• manage products;
• work regularly in the CMS;

then creating a properly permissioned account is more appropriate.

Do not force a preview-link workflow onto a real editorial collaboration process merely to avoid creating a user.

Use the minimum role required

When an account is genuinely needed, use the smallest set of permissions required by the workflow.

The distinction between roles and capabilities is covered in WordPress user roles and capabilities, explained.

WordPress’s developer documentation explicitly recommends checking capabilities rather than assuming a role name alone should authorize sensitive operations. See the official Roles and Capabilities API.

A reviewer who only needs to edit their own drafts may require dramatically fewer capabilities than someone responsible for publishing the entire site.

Review pending content before publication

WordPress includes a Pending Review state specifically for editorial workflows.

The WordPress documentation describes Pending content as content waiting for someone with sufficient publishing permissions to review it before publication.

The process might be:

Author creates draft
        ↓
Content becomes Pending Review
        ↓
External stakeholder receives preview link
        ↓
Feedback collected
        ↓
Editor updates content
        ↓
Final approval
        ↓
Publish

This keeps publication under WordPress permissions while still allowing an external person to inspect the page.

Scheduled posts are another useful case

Suppose a press release is scheduled for:

September 1
09:00

The legal team needs to review it on August 28.

WordPress supports scheduling through the post settings interface, where content can remain in a future state until its configured publication date.

Instead of publishing the article early:

Status:
Scheduled

Preview link:
Legal review

Expiry:
Thursday evening

Password:
Enabled

The post remains scheduled while the reviewer sees the real rendered version.

Private content can also need temporary external review

A WordPress private post is normally visible only to appropriately privileged authenticated users.

Sometimes a private item needs temporary external review before the final access strategy is determined.

TheOneWP Preview Links can also create links for private posts, allowing a controlled exception without changing the underlying post status.

Track whether preview links are actually being used

When several reviewers receive links, it can be useful to know whether a link has been opened.

For example:

Client review
Views: 3

Legal review
Views: 0

This does not prove that someone read every word, obviously. Humans have developed scrolling.

But it can tell you whether the access path has at least been used.

Do not use raw IP logging unless you genuinely need it

Access logging should collect only the information necessary for the workflow.

TheOneWP Preview Links hashes visitor IP values before storing them rather than retaining the original IP address directly.

This allows repeated access patterns to be distinguished without making raw addresses the central identity mechanism.

A hashed address still does not identify a person

Several people may share one public IP address.

One person may use several addresses.

VPNs, mobile networks and proxies complicate this further.

Use preview logs as operational context, not as forensic proof that a specific named individual read the draft.

Revoke links when they are no longer needed

If access should end before the configured expiration, revoke the link.

Common reasons include:

• the reviewer changed;
• the URL was accidentally forwarded;
• the review round ended;
• the content was abandoned;
• a replacement preview link was created.

Revocation should be immediate rather than requiring changes to the actual WordPress user system.

Remember that revocation may remove associated log history

In TheOneWP, revoking a Preview Link also removes its associated view log.

If the access history matters for the project, export or record the relevant information before revoking the link.

Use a separate link for each review round when useful

For structured client approval, you may want:

Round 1:
Client review R1

Round 2:
Client review R2

Final:
Final approval

This can make it easier to distinguish which access record belongs to which stage of the review.

It also lets you revoke old rounds once they are no longer relevant.

Do not change the reviewed version continuously

A preview link shows the current underlying draft.

If the developer changes that draft while the client is actively reviewing it, feedback can become confusing.

For example:

10:00 Client opens version A
10:10 Developer changes headline
10:15 Client reports headline from version A
10:20 Developer sees version B

For formal approvals, freeze the content during the review window or clearly identify when a new revision becomes ready for review.

WordPress revisions help when feedback changes the content

WordPress revisions preserve historical versions of post content while editing.

The normal WordPress editor exposes revision history so previous changes can be compared or restored when necessary.

See How WordPress post revisions work for the practical WordPress workflow.

The official WordPress editing documentation also describes how revisions can be browsed from the editing interface.

Preview links and revisions solve different problems:

Preview link
→ who can temporarily view the draft

Revision
→ which historical version of the draft existed

Do not put preview URLs into menus or permanent internal links

A preview URL is temporary infrastructure.

Do not build public navigation around it.

This would create:

Published page
→ temporary preview link
→ link expires
→ broken navigation

Once the final page is published, internal links should point to the permanent public URL.

Preview links should stay out of XML sitemaps

An XML sitemap should represent URLs that belong to the site’s public search architecture.

Temporary review URLs do not.

Google recommends including canonical URLs that you actually want search engines to crawl and consider for indexing in your sitemap. Its sitemap documentation covers this relationship.

For a deeper WordPress explanation, see What is an XML sitemap, and why does it matter?.

TheOneWP XML Sitemap is designed around public canonical content rather than temporary preview-token URLs.

Preview links do not replace staging

A shareable draft link solves a content-level review problem.

It does not create a complete isolated testing environment.

If the work requires changes to:

• theme templates;
• plugins;
• navigation;
• global CSS;
• checkout;
• authentication;
• database structures;
• integrations;

use staging.

The distinction keeps a simple content-review tool from being stretched into something it was never intended to be.

A practical draft-sharing workflow

For ordinary client or stakeholder review, a clean process can look like this:

1. Create or edit the content in WordPress.
2. Keep the post as Draft, Pending Review, Scheduled or Private.
3. Complete an internal review first.
4. Create a dedicated preview link.
5. Give the link a clear label.
6. Set an expiration appropriate to the review window.
7. Add a password if the content is sensitive.
8. Add a reasonable view limit if useful.
9. Send the link to the reviewer.
10. Collect feedback through your normal project channel.
11. Apply revisions.
12. Repeat the review process if necessary.
13. Publish once approved.
14. Use the final permalink after publication.
15. Revoke or clean up temporary review access.

Example: sharing a landing page with a client

Imagine a new landing page is being prepared for a campaign.

The page is not ready to publish because pricing still needs approval.

The workflow could be:

Post status:
Draft

Preview link label:
Client pricing review

Expires:
3 days

Password:
Enabled

Maximum views:
10

The client can review the actual responsive landing page without accessing wp-admin or forcing the draft into a published state.

Example: legal review of a scheduled announcement

A company announcement is scheduled for Friday.

Legal needs to approve it on Wednesday.

Instead of publishing it early:

Status:
Scheduled

Preview link:
Legal review

Expiry:
Thursday evening

Password:
Enabled

The post remains scheduled while the reviewer sees the real rendered version.

Example: proofreader reviewing multiple drafts

If the same proofreader regularly reviews many posts, creating a WordPress account may eventually make more sense.

The decision can be based on frequency:

One-off reviewer
→ Preview Link

Occasional external client
→ Preview Link

Permanent editorial collaborator
→ WordPress account with appropriate role

The goal is not to eliminate accounts. It is to avoid creating accounts where they provide no real benefit.

Common mistakes when sharing WordPress drafts

Creating an Administrator account for a client who only needs to read

Access should match the task.

Sending the normal logged-in WordPress preview URL

It is not designed as a reusable anonymous sharing mechanism.

Publishing the page temporarily

A review requirement should not force unfinished content into the public website.

Using screenshots for interactive reviews

The reviewer cannot evaluate the actual implementation.

Using one permanent shared login

Credentials remain usable long after the original review ends.

Leaving preview links active forever

Temporary access should have a lifecycle.

Setting an impractically low view limit

Legitimate reviewers may need to reopen the page.

Forgetting search engine indexing

Reachable unpublished content should not silently become a search landing page.

Using noindex as though it were authentication

Search visibility and access control solve different problems.

Using preview links for whole-site testing

Staging is the better tool for interconnected site changes.

Keeping feedback inside screenshots and random messages

The preview provides access. A separate structured system should track decisions.

WordPress draft sharing checklist

• Confirm that the reviewer only needs read access.
• Keep the content unpublished.
• Use a dedicated preview link rather than a temporary user account when appropriate.
• Create separate links for separate reviewers where useful.
• Label each link clearly.
• Set a reasonable expiration.
• Add password protection for sensitive material.
• Use view limits only when they benefit the workflow.
• Keep preview content out of search engines.
• Do not add preview URLs to XML sitemaps.
• Do not create permanent internal links to preview URLs.
• Keep feedback in a defined review channel.
• Freeze important versions during formal review.
• Use WordPress revisions to preserve content history.
• Publish only after approval.
• Share the final public permalink after publication.
• Revoke temporary access when it is no longer needed.
• Create a real WordPress account instead when ongoing editing access is required.

Related WordPress publishing and review guides

For the other parts of sharing, reviewing and publishing WordPress content, continue with:

• Why noindex matters for unpublished content
• Setting up a client review workflow in WordPress
• WordPress staging site best practices
• How WordPress post revisions work
• WordPress user roles and capabilities, explained
• Robots.txt vs real access control
• What is an XML sitemap, and why does it matter?
• Preview Links
• Site Password Protection
• XML Sitemap

Final thoughts

Sharing a WordPress draft without creating an account is fundamentally about separating content access from site access.

A client who only needs to read one draft does not necessarily need a username, role, password-reset flow and access to WordPress. They need a controlled way to view one piece of unpublished content.

TheOneWP Preview Links provides that narrower access through individually manageable token-based links, with optional passwords, expiration dates and view limits. Preview responses remain outside normal search indexing, and once the post is published the old review link redirects to the real public permalink.

For larger projects, use Site Password Protection or a properly isolated staging environment instead. For ongoing collaborators who actually need to work inside WordPress, create a real user with the appropriate role.

The right solution is therefore not “never create an account.” It is simpler: do not create an account when all someone needed was a link.