How Agencies Quality-Check Outsourced WordPress Work

The message from your partner says “done, ready for review.” You forward it to the client with a cheerful note. An hour later the client replies: the new pricing table looks great on desktop, but on their phone it runs off the side of the screen, and the enquiry form at the bottom no longer sends. Your partner did what was asked. Nobody checked what was around it.

That gap between “the task is finished” and “the site is ready for the client to see” is where outsourced work goes wrong most often, and it is the agency’s gap to close. This post is a practical way to close it: what to agree before work starts, a checklist you can run in a short sitting, how to ask your partner for proof rather than promises, and how to send work back without making it personal.

Why the final check is yours, even when the partner is good

When you outsource WordPress work, your client never sees the developer. They see you. If a broken form reaches them, it is your broken form. A capable partner will test their own work, and you should expect that, but they are testing against the brief they were given. You know things they often do not: that this client always looks at the site on an older iPhone first, that the managing director reads every page on a tablet, that the contact form feeds a CRM somebody set up years ago.

So think of quality checking as two layers. The partner checks that the work matches the brief. You check that the result matches the client. Both layers matter, and neither replaces the other. If you are still setting up how outsourcing fits into your agency, the wider picture is in our guide to outsourcing WordPress work as an agency; this post stays on the review step.

Decide what “done” means before anyone starts

Most review arguments are really arguments about the brief. If the task said “add a pricing table to the services page,” there is no shared idea of what finished looks like. Before the work begins, write two or three acceptance criteria in plain sentences. For example:

• The pricing table shows all four plans in one row on desktop and stacks one plan per row on phones.
• The “Book a call” button in each plan opens the existing booking page, not a new one.
• Nothing else on the services page changes position or styling.

That third line is the one people forget, and it is the one that saves the most trouble. It tells your partner that side effects count as defects. It also gives you something objective to check against later, so feedback becomes “criterion three is not met” rather than “it feels off.” There is more on writing that kind of request in our post on briefing a remote developer so they can act without waiting.

A review checklist you can run in one sitting

You do not need to test the whole site after every change. You need to test the change, the things it touches, and the handful of things that would embarrass you if they broke. Work through the groups below in order. Where the work was done on staging, run the list there first and again, briefly, on the live site after deploy.

1. The change itself

• Open the brief and the acceptance criteria side by side with the page. Tick each criterion, one at a time.
• Check the text for typos, placeholder copy (“Lorem ipsum”, “Button text”) and wrong phone numbers or emails. These slip through more than code errors do.
• Click every new link and button. Confirm each goes where it should, and that external links open as the client prefers.
• If the change involves images, check they are sharp, cropped sensibly on smaller screens, and carry useful alt text.

2. Everything near the change

• Look at the sections directly above and below the edited area. Spacing, fonts and colours are the usual casualties.
• If a shared element was touched, such as a header, footer, global style or reusable block, open two or three other pages that use it.
• If a plugin was added or updated, visit the pages where that plugin does its work, not just the page in the brief.

3. Phones, tablets and more than one browser

• Check on a real phone, not only the browser’s responsive mode. Tap targets, sticky headers and pop-ups behave differently on a real device.
• Rotate the phone sideways once. Wide-screen layouts on a phone break surprisingly often.
• Open the page in at least one browser you do not normally use. If you live in Chrome, try Safari or Firefox.
• Log out, or use a private window. Many caching and permission problems only appear to visitors who are not logged in.

4. The things that make the client money

• Submit every form on the edited pages with real-looking details, and confirm the email arrives where the client expects it. A form that shows “thank you” but sends nothing is the classic silent failure. Our post on contact forms that stop working covers the common causes.
• On a store, add a product to the cart, change the quantity, and go as far through checkout as the payment setup allows in test mode.
• If the site books appointments or takes sign-ups, run one end to end.

5. Speed and hidden errors

• Load the page with the cache cleared and compare how it feels with before. You do not need a lab score; you are looking for a change you can notice.
• Open the browser’s developer console and reload. New red errors after a change are worth a question, even if the page looks fine.
• Run a quick check for broken links on the edited pages if many links changed. The approach in finding broken links on a site works for a single section as well as a whole site.

6. Housekeeping

• Test pages, draft duplicates and temporary admin users created during the work should be removed or flagged.
• If the work was done on staging, confirm the staging site is not open to search engines and that the live site’s “discourage search engines” setting was not copied across by mistake.
• Check that a backup was taken before the change and that you know where it is.

Ask for evidence, not reassurance

“All tested, looks good” tells you very little. A short written note from your partner tells you a lot, and it makes your own review faster because you can see what has already been covered. Ask for these with every job:

1. What changed. Pages, templates, plugins, settings. Specific names, not “updated some styles.”
2. What was tested and how. Which devices or screen sizes, which forms were submitted, whether checkout was tested.
3. What was not tested, and why. This is the most valuable line. “Could not test the payment step because the gateway is in live mode” tells you exactly where to look.
4. Anything noticed but left alone. A good developer will spot an unrelated problem and mention it rather than quietly fixing it outside scope.
5. How to undo it. Where the backup is, or what to switch off if something goes wrong after deploy.

A partner who resists writing notes like this is telling you something about how they work. A partner who sends them unprompted is one you can relax with sooner.

Use staging and approvals so the client never sees a draft

The simplest quality rule is that the client should see finished work only. That means changes happen somewhere other than the live site, you review them there, and only then does anything move. If your current process has the partner editing live sites directly, fixing that will prevent more problems than any checklist. Our post on running staging, approvals and deploys for client sites sets out one way to organise it.

Where a staging copy is not practical, such as a quick text change on a small brochure site, agree that the partner takes a backup first and tells you the moment the change is live, so you can check it before the client does.

Sending work back without souring the relationship

Rejected work is normal. What damages a partnership is vague or emotional feedback. Keep it specific, tied to the brief, and free of blame. Something like:

“Thanks for this. Two things before it goes to the client. First, criterion two: the ‘Book a call’ buttons open /contact/ rather than /book/. Second, on an iPhone in portrait, the table’s third column is cut off (screenshot attached, URL in the address bar). Everything else checks out. Could you fix these and add a line to your notes saying what you retested?”

Notice what that message does. It names what passed, so the partner does not redo good work. It points to the criterion, so nobody argues about intent. It includes a screenshot with the address visible. And it asks for retest notes, so the second review is quicker than the first.

If the same kind of issue keeps coming back, say mobile layouts or forgotten test pages, raise it once as a pattern rather than every time as a fresh complaint. Add it to the brief template so it becomes part of the definition of done.

How much checking is enough?

Match the depth of the review to the risk. A typo fix on an About page needs a glance. A plugin update on a store needs the money checks. A theme change needs most of the list.

Over time, as your partner’s notes prove reliable, you can lean on them more and spot-check rather than retest. That trust should be earned through a record of accurate notes, not assumed from the start.

Keep a short record

A line in the client’s site notes after each job, with the date, what changed, who reviewed it and anything left open, pays for itself the first time a client asks “when did this start?” It also shows you which kinds of work tend to come back for fixes, which is useful when you are estimating the next job.

If you want a partner that writes those notes as a matter of course and expects your review before anything reaches the client, that is how our behind-the-scenes bug fixing for agencies is set up. Either way, keep the final check in your hands.

Next in this series: How to Brief an Outsourced Developer So They Can Act