Setting up a client review workflow in WordPress

Setting up a client review workflow in WordPress means giving clients a controlled way to inspect work, provide feedback and approve changes before those changes reach the public website. The difficult part is rarely creating a page for someone to look at. The difficult part is making sure they are reviewing the correct version, that unfinished content is not publicly exposed and that feedback turns into a clear approval rather than another endless round of vaguely described changes.

A useful WordPress review workflow separates development, review, revision and publication into distinct stages.

The client should know what they are reviewing. The developer should know which feedback belongs to which version. Unpublished pages should remain protected. Production should not change while approval is still pending. And once the client approves a version, the team should have a clear path to deployment.

This guide explains how to build that process using staging environments, WordPress post statuses, preview links, access restrictions, revisions, user roles and a structured feedback and approval process.

What is a client review workflow in WordPress?

A client review workflow is the process used to move work from an internal draft to client approval and finally to production.

A simple version looks like:

Development
    ↓
Internal QA
    ↓
Client review
    ↓
Feedback
    ↓
Revision
    ↓
Client approval
    ↓
Production deployment
    ↓
Final validation

The exact tools can vary, but the separation between those stages is important.

Without it, teams often end up with a workflow that looks more like:

Developer changes live site
    ↓
Client notices something
    ↓
Client sends screenshot
    ↓
Developer changes something else
    ↓
Nobody knows which version was approved

Technically, that is still a workflow. So is falling down a staircase.

Do not use the production site as the main review environment

For significant design, development or structural work, client review should normally happen before the changes reach production.

A staging environment is useful because it gives you a separate version of the website where changes can be reviewed without immediately affecting visitors.

A typical setup might be:

Production:
https://example.com/

Staging:
https://staging.example.com/

Staging can contain:

• new templates;
• new pages;
• design changes;
• updated navigation;
• plugin changes;
• new content;
• new forms;
• integration changes.

For the broader technical setup, see WordPress staging site best practices.

A review environment should resemble production

The usefulness of client review depends on how accurately the review environment represents the final site.

If staging uses different:

• content;
• plugins;
• theme code;
• PHP configuration;
• responsive assets;
• fonts;
• integration behavior;

then client approval may not mean much.

The client needs to review something reasonably close to what will actually be deployed.

This does not mean staging must duplicate every production integration. Email, analytics, payments and webhooks often need safe test configurations. The visual and functional experience being approved, however, should be representative.

Protect the review environment from public access

A staging site should not be considered private simply because nobody has advertised its URL.

Addresses such as:

staging.example.com
dev.example.com
new.example.com
preview.example.com

can still be discovered through links, logs, browser history, DNS records and automated crawling.

If the environment is intended only for your team and the client, use real access control.

TheOneWP Site Password Protection can place the public WordPress site behind a shared password while allowing logged-in users to bypass the gate.

This is particularly useful for staging or pre-launch review environments where the client needs to browse several pages rather than inspect one isolated draft.

Password protection and noindex solve different problems

A search-engine directive is not the same thing as preventing access.

A noindex instruction asks compliant search engines not to index a page.

Password protection prevents an unauthorized visitor from reading it in the first place.

For a client review environment containing unpublished work, credentials, unreleased products or confidential information, actual access restriction is considerably more appropriate than relying only on crawler directives.

This distinction is covered more broadly in Robots.txt vs real access control.

Use preview links when the client only needs to review individual content

A complete staging environment is not always necessary.

Sometimes the client only needs to review:

• one draft article;
• one landing page;
• a scheduled announcement;
• a private page;
• a revised piece of content.

Creating a WordPress account just so someone can inspect one draft introduces unnecessary administration.

TheOneWP Preview Links can generate a temporary shareable URL for unpublished WordPress content so a reviewer can view it without receiving a WordPress user account.

For that specific workflow, see Sharing a WordPress draft without creating an account.

Choose staging or preview links based on what is being reviewed

The two approaches solve different review problems.

Use staging when the client needs to review:

• an entire redesign;
• navigation changes;
• multiple connected pages;
• responsive behavior across the site;
• forms and interactions;
• theme changes;
• plugin behavior;
• checkout or membership workflows.

Use a preview link when the client needs to review:

• one draft;
• one unpublished landing page;
• one scheduled post;
• one revised piece of content;
• a small number of isolated pages.

Using the smallest review environment that accurately represents the work makes the process easier for everyone.

Do not create client WordPress accounts unless they actually need them

A client account makes sense when the client needs ongoing access to WordPress.

For example, they may need to:

• edit content;
• approve posts;
• manage products;
• view orders;
• perform administrative tasks;
• maintain the site after handoff.

If all they need to do is look at a page and approve it, an account may be unnecessary.

Every account introduces:

• credentials;
• password resets;
• role configuration;
• permissions;
• security responsibility;
• future account cleanup.

A preview link or protected staging environment can often keep the review workflow much simpler.

If clients need accounts, give them the minimum necessary permissions

If the client genuinely needs WordPress access, assign the smallest role or capability set that allows them to complete their task.

Do not automatically create another Administrator because it saves thirty seconds during setup.

The official WordPress Roles and Capabilities documentation explains how roles define collections of permissions.

For a practical explanation of the system, see WordPress user roles and capabilities, explained.

Separate reviewing from editing

One of the most useful workflow decisions is determining whether the client is supposed to:

• review;
• comment;
• edit;
• approve.

Those are not the same action.

If the client is expected only to review a design, giving direct editing access may make the process harder.

Instead of saying:

Please make any changes directly.

a cleaner process may be:

Please review this version.

Send feedback using the agreed format.

We will apply the revisions.

You will receive a new review version.

This keeps the implementation under one person’s control while feedback remains traceable.

Define exactly what the client is reviewing

Every review request should explain its scope.

For example:

Review round: 2

Pages:
- Homepage
- About
- Services
- Contact

Review:
- Layout
- Copy
- Images
- Mobile appearance

Not part of this round:
- Final SEO metadata
- Cookie banner
- Checkout
- Analytics

This prevents feedback on unfinished areas from becoming mixed with feedback on work that is actually ready for approval.

Do internal QA before sending anything to the client

The client should not be the first person testing your own work.

Before review, check:

• desktop layout;
• tablet layout;
• mobile layout;
• navigation;
• broken links;
• forms;
• images;
• typography;
• browser console errors;
• obvious placeholder content;
• 404 pages;
• login behavior where relevant.

A client review round should focus on decisions and approval, not on finding that the mobile menu does not open.

Give the review round a version or date

Feedback becomes much easier to manage when every review request identifies the version being discussed.

For example:

Homepage review
Version: 3
Sent: August 20, 2026

or:

Review Round 02
Build: 1.4.0

The exact naming system does not matter as much as consistency.

When feedback later says:

The heading was better in the previous version.

you need to know what “previous” actually means.

Use WordPress revisions for content history

WordPress can keep historical revisions of posts and pages as they are edited.

This is useful when:

• copy changes several times;
• a client asks to restore earlier wording;
• multiple editors change content;
• an approved version is accidentally modified.

The WordPress configuration system supports retaining post revisions, and they provide a recoverable history rather than forcing you to remember exactly what paragraph existed three review rounds ago.

See How WordPress post revisions work for a deeper explanation.

Do not disable revisions during an active review process

Aggressive database optimization during an approval workflow can be counterproductive.

If a page is being repeatedly rewritten during client review, revision history is one of the few times where those extra database rows are immediately useful.

You may choose to limit how many revisions WordPress retains, but completely disabling them during active editing removes an easy recovery mechanism.

Use WordPress post statuses intentionally

WordPress supports several built-in content states, including:

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

The official WordPress post status documentation lists the standard statuses available to content.

These can help distinguish internal work from content ready for approval.

For example:

Draft
→ actively being written

Pending Review
→ internally complete and waiting for review

Published
→ approved and public

Your exact editorial process may differ, but statuses are useful only when the team agrees what each one means.

Pending Review does not automatically mean client-approved

The WordPress label Pending Review is simply a post status.

It does not magically record:

• who reviewed the content;
• what they approved;
• which revision was approved;
• when the approval happened;
• whether design and copy were both accepted.

If formal client approval matters, record it separately.

Choose one feedback channel

A client review workflow becomes difficult to manage when feedback arrives simultaneously through:

• email;
• WhatsApp;
• Slack;
• phone calls;
• PDF comments;
• screenshots;
• WordPress;
• meeting notes.

Pick one primary feedback location.

This could be:

• a project-management task;
• a shared document;
• a ticket;
• a dedicated email thread;
• an annotation platform;
• a structured feedback form.

The tool matters less than having one authoritative place where unresolved feedback can be found.

Ask clients to identify the page and the element

Feedback such as:

I don't like the text.

is technically information, in the same generous sense that fog is technically weather.

A useful feedback format includes:

Page:
Services

Section:
Web Development

Current:
"Build something better"

Requested change:
Replace with:
"Custom web development for growing businesses"

For visual feedback:

Page:
Homepage

Viewport:
Mobile

Section:
Hero

Issue:
Image is too tall and pushes CTA below the fold.

This dramatically reduces interpretation time.

Separate bugs from preferences

Not all client feedback represents the same type of work.

Useful categories include:

• Bug: something does not work as intended;
• Content change: text or media needs updating;
• Design change: visual direction should change;
• Scope change: new functionality or deliverable is being requested;
• Question: clarification is required before changing anything.

This distinction is especially important when contracts include a limited number of revision rounds.

Fixing a broken button is not the same thing as redesigning a section that previously received approval.

Use review rounds instead of continuous feedback

A structured workflow usually works better when feedback is collected into rounds.

For example:

Review Round 1
Client submits complete feedback
        ↓
Agency implements changes
        ↓
Internal QA
        ↓
Review Round 2
Client checks revised version
        ↓
Final corrections
        ↓
Approval

This is more efficient than receiving one comment every twenty minutes for four days while the developer continuously changes the same page underneath the reviewer.

Freeze the reviewed version while feedback is being collected

If possible, avoid changing the reviewed interface while the client is still evaluating it.

Otherwise this can happen:

10:00 Client opens homepage
10:15 Developer changes hero
10:30 Client comments on old hero
10:45 Developer sees feedback about something that no longer exists

For important reviews, establish a freeze:

This version is ready for review.
No new changes will be deployed until feedback closes.

After the feedback deadline, development can continue.

Set a review deadline

Client review without a deadline can suspend a project indefinitely.

A review request should clearly state:

• when the review starts;
• which pages are included;
• where feedback should be submitted;
• when feedback is due;
• what happens after the deadline.

For example:

Review opens:
August 20

Feedback due:
August 24

Revision round:
August 25–26

Final approval:
August 27

This turns review into a project stage instead of a vague state of waiting.

Preview links should have a controlled lifetime

A shareable preview URL should not necessarily remain valid forever.

Once a review is complete, old review access may no longer serve a purpose.

Preview Links allows generated preview links to be managed and revoked when access should end.

This makes temporary review access preferable to publishing unfinished content simply because a client needs to see it.

Do not use screenshots as the primary website review method

Screenshots are useful for discussing a specific visual issue.

They are poor substitutes for reviewing an actual website.

A screenshot cannot reliably demonstrate:

• responsive behavior;
• hover states;
• navigation;
• forms;
• animation;
• scroll behavior;
• interactive components;
• browser rendering.

Whenever possible, let the client review the real implementation in a controlled environment.

Test responsive layouts with the client review process in mind

Clients frequently review websites on whichever device is nearest when they receive the link.

That means your review version should already have been tested on common viewport sizes.

Do not send a desktop-only layout and then explain afterward that mobile “has not been done yet” unless the review scope explicitly says that.

If only one breakpoint is ready, state that clearly before the client begins reviewing.

Make the staging environment visually identifiable

Clients can easily confuse staging and production when both look almost identical.

Add an obvious indicator such as:

STAGING
CLIENT REVIEW
NOT LIVE

This can appear in:

• the admin bar;
• a small frontend badge;
• the browser title;
• the login page;
• a fixed development notice.

The goal is to prevent a client from reviewing production while believing they are looking at staging, or worse, sharing the staging URL publicly because it looks finished.

Keep staging out of production analytics

Client review sessions can produce substantial traffic.

If staging uses the same analytics configuration as production, internal review sessions may pollute:

• page views;
• session counts;
• conversion data;
• funnels;
• heatmaps;
• behavior reports.

Disable production analytics on staging or use a separate property where testing data matters.

Prevent staging from sending real customer emails

A staging database may contain real customer information copied from production.

During review, actions performed by the client could accidentally trigger:

• order emails;
• password emails;
• membership notifications;
• contact automations;
• marketing sequences.

Review copied integrations before giving anyone access to the environment.

This is one of the reasons WordPress staging site best practices treats email, payment and webhook isolation as part of the staging setup rather than optional tidying.

Do not use live payment credentials during client review

If the review includes ecommerce, use test or sandbox payment configurations wherever the provider supports them.

A client clicking through checkout should not accidentally create a real transaction while trying to confirm that a button is the right shade of blue.

Create a clear approval checkpoint

Feedback completion and approval are different things.

The client may submit their final comments, you may implement all of them, and the resulting version may still need explicit confirmation.

A useful final stage is:

All Round 2 feedback implemented.

Review version:
v1.8

Please confirm one of the following:

[ ] Approved for production
[ ] Additional corrections required

This creates an identifiable point after which deployment may proceed.

Record what was approved

Approval should identify the reviewed version.

For example:

Approved:
Homepage v4
Services v3
Contact v2

Approved on:
August 27, 2026

This matters when a dispute later involves a page that was changed again after approval.

Do not keep changing approved work silently

Once the client approves a version, treat significant subsequent changes as new changes.

If you alter:

• layout;
• copy;
• navigation;
• functionality;
• pricing;
• forms;
• important imagery;

after approval, the final production version may no longer be the version the client approved.

Small technical corrections may not require another review, but material changes should be communicated.

Create a deployment checkpoint after approval

Approval should not trigger an uncontrolled push to production.

Before deployment:

• create a current backup;
• confirm production has not changed unexpectedly;
• identify database changes;
• identify file changes;
• review caches;
• confirm environment-specific settings;
• review integrations;
• prepare a rollback path.

The review process confirms that the work is acceptable. Deployment still needs its own technical controls.

Do not overwrite new production data with an old staging database

This is especially important on active sites.

During the review period, production may receive:

• orders;
• users;
• form submissions;
• comments;
• bookings;
• memberships;
• content edits.

If staging was cloned days or weeks earlier, blindly replacing the production database with the staging database can destroy those newer records.

Deploy the required changes intentionally rather than treating staging as a frozen replacement for all production data.

Run production QA after deployment

Client approval on staging does not eliminate the need to verify the live site.

After deployment, check:

• homepage;
• approved pages;
• navigation;
• responsive layout;
• forms;
• login;
• checkout where relevant;
• analytics;
• email;
• structured data;
• canonical URLs;
• search visibility;
• caches.

Production can behave differently because infrastructure, cache layers, credentials and data are different.

Remove temporary review access after launch

Once the site or content is live, clean up the temporary review mechanisms.

This may include:

• revoking preview links;
• removing client test accounts that are no longer required;
• removing the staging password from a production deployment;
• removing test credentials;
• removing review banners;
• cleaning temporary content;
• removing abandoned staging environments.

Temporary infrastructure has a remarkable tendency to become permanent infrastructure when nobody schedules its removal.

Decide whether the client keeps WordPress access after handoff

A review account and a long-term ownership account are different things.

At handoff, decide:

• who owns administrator access;
• which client users remain;
• which roles they receive;
• who owns plugin licenses;
• who manages hosting;
• who manages backups;
• who is responsible for future updates.

If roles changed several times during development, How to audit user roles on a WordPress site provides a useful post-project review process.

A practical client review workflow

A clean WordPress agency workflow can look like this.

Phase 1: build

1. Develop locally or on staging.
2. Keep production unaffected.
3. Use representative content.
4. Complete initial responsive implementation.

Phase 2: internal QA

1. Check desktop, tablet and mobile.
2. Test navigation.
3. Test forms and interactions.
4. Remove placeholder content.
5. Review browser errors.

Phase 3: prepare client access

1. Protect staging from public access.
2. Or generate preview links for individual drafts.
3. Make the review environment clearly identifiable.
4. Disable unsafe production integrations.

Phase 4: open review

1. Define the review scope.
2. Identify the review version.
3. Provide the review URLs.
4. Explain the feedback format.
5. Set the feedback deadline.
6. Freeze the version while it is being reviewed.

Phase 5: implement feedback

1. Consolidate all feedback.
2. Separate bugs, revisions and scope changes.
3. Implement approved corrections.
4. Use revision history where necessary.
5. Run internal QA again.

Phase 6: final approval

1. Send the final review version.
2. List what changed.
3. Request explicit approval.
4. Record the approved version and date.

Phase 7: deployment

1. Create a fresh backup.
2. Deploy approved changes.
3. Avoid overwriting newer production data.
4. Clear relevant caches.
5. Run production QA.

Phase 8: cleanup and handoff

1. Revoke temporary preview links.
2. Remove unnecessary test accounts.
3. Remove review indicators.
4. Confirm permanent client roles.
5. Document ownership and maintenance responsibilities.

Example client review request

A review request can be concise while still removing ambiguity:

Client Review – Round 2

Environment:
https://staging.example.com/

Pages:
Homepage
Services
About
Contact

Please review:
Copy
Images
Layout
Mobile presentation

Feedback deadline:
August 24

Submit feedback:
Project task #42

Please group all feedback into one review round.

Not included:
SEO metadata
Analytics
Final redirects

This gives the client enough information to review productively without requiring them to understand your entire development process.

Example final approval request

Final Review

All Round 2 feedback has been implemented.

Version:
1.8

Please confirm:

APPROVED FOR PRODUCTION

or

ADDITIONAL CHANGES REQUIRED

The important part is making approval explicit rather than assuming silence means acceptance.

Common client review workflow mistakes

Reviewing directly on production

Unapproved work becomes visible to real visitors and may affect business processes.

Leaving staging publicly accessible

An obscure subdomain is not an access-control system.

Creating administrator accounts for every reviewer

Most reviewers do not need administrative privileges.

Giving clients unfinished work without defining the scope

They will naturally review everything they can see.

Accepting feedback through several unrelated channels

Important corrections become difficult to track.

Changing the reviewed version while feedback is still arriving

Reviewer comments can refer to an interface that no longer exists.

Using screenshots instead of the real implementation

Responsive and interactive behavior cannot be reviewed properly.

Skipping internal QA

The client ends up debugging the site for you.

Failing to record approval

Nobody can later establish which version was actually accepted.

Deploying the entire staging database over live data

Orders, users and other newer production records can be lost.

Leaving temporary preview access active forever

Review links and test accounts should have a lifecycle.

Client review workflow checklist

• Use staging for substantial site-wide changes.
• Use preview links for isolated unpublished content.
• Protect staging with real access control.
• Prevent staging from being indexed.
• Disable or isolate production analytics.
• Disable unsafe email and payment integrations.
• Run internal QA first.
• Define exactly what the client should review.
• Give each review round a version.
• Choose one feedback channel.
• Require page and section references in feedback.
• Separate bugs from revisions and scope changes.
• Freeze the reviewed build while feedback is collected.
• Set a feedback deadline.
• Use WordPress revisions during active editing.
• Use client accounts only when genuinely required.
• Grant minimum necessary permissions.
• Request explicit final approval.
• Record the approved version.
• Create a fresh backup before deployment.
• Avoid overwriting newer production data.
• Run production QA.
• Revoke temporary access afterward.
• Document the final handoff.

Related WordPress review and staging guides

For the other parts of a structured WordPress review and approval process, continue with:

• Sharing a WordPress draft without creating an account
• WordPress staging site best practices
• How WordPress post revisions work
• WordPress user roles and capabilities, explained
• How to audit user roles on a WordPress site
• Robots.txt vs real access control
• Preview Links
• Site Password Protection

Final thoughts

Setting up a client review workflow in WordPress is primarily about removing ambiguity from the period between “the work exists” and “the work is approved.”

Use staging when the client needs to experience a complete website or connected workflow. Use temporary preview access when they only need to inspect individual unpublished pages. Protect anything that should not yet be public, and avoid creating user accounts or granting administrator access merely because sharing a draft otherwise feels inconvenient.

TheOneWP Preview Links provides controlled access to individual unpublished posts and pages, while Site Password Protection is better suited to protecting an entire staging or review environment.

The technical tools only solve part of the problem. The rest comes from process: define the review scope, use versioned rounds, centralize feedback, freeze the version being reviewed, request explicit approval and deploy only the version that was actually accepted.

When those stages are clear, client review stops being a stream of screenshots and contradictory messages and becomes what it should have been all along: a controlled path from unfinished work to approved production.