WordPress quality checklist: what to ask your agency

Most WordPress quality problems are visible before anyone opens the code. The signals are in the rendered HTML, in the page-speed report, in the plugin list, and in the answers an agency gives when you ask them how they work. According to W3Techs, WordPress runs on roughly 41.9 percent of all websites and 59.5 percent of websites with a known content management system. The size of the installed base is also the reason build quality on WordPress varies so much from one site to the next. The same platform sits underneath sites that were built with serious engineering discipline and sites that were assembled out of a commercial theme, a heavy page builder, and thirty plugins. Telling the two apart takes a short, structured audit run at three moments where the buyer has the most leverage, and a non-technical buyer can do every step of it without writing a line of code.

This guide is a WordPress quality checklist organized around the three stages of a build where a non-technical buyer can act: verify a live site for yourself, ask the right questions at kickoff before signing, and demand specific proof at handover. The framework applies to any WordPress build, including ones Keroberos delivers.

Why most WordPress builds disappoint

Disappointing WordPress sites are rarely WordPress's fault. They are usually the result of three habits stacked together, and each one is visible after the build is done. The first is a commercial theme used as the structural foundation, with a heavy page builder layered on top to compensate for what the theme cannot do. The second is a plugin estate that grew during the build because every requirement that did not have an obvious solution was solved by installing a new plugin. The third is a launch where security hardening, performance work, and accessibility audits were all classified as things to do "after go-live", which in practice means never.

None of those choices is fatal in isolation. Together they produce a site that is slow, fragile, and expensive to maintain. The security exposure is real and quantifiable. Patchstack's 2026 State of WordPress Security whitepaper recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42 percent year-over-year increase, with 91 percent of those vulnerabilities found in plugins and 9 percent in themes. Only 6 were in WordPress core itself. More striking: 46 percent of those vulnerabilities had not received a patch by the time of public disclosure, meaning the gap between knowing the vulnerability exists and being able to fix it was indefinite. On a WordPress site, choosing which plugins to install is a security decision dressed up as a feature decision. Under-built sites fail because the build accumulated attack surface that nobody on the team was responsible for, not because WordPress itself is insecure.

The three-stage audit

The buyer has three distinct windows of leverage on a WordPress build. Each one calls for a different kind of evidence, and the sequence matters: the questions you ask at stage two only land if you already know what to look for at stage one, and the artifacts you demand at stage three only have weight if the kickoff conversation set the expectation that they would be required.

Stage 1: Verify yourself on the live site

A non-technical buyer can run this audit on any live WordPress site in about fifteen minutes, using only a browser, the page-source view, and Google PageSpeed Insights. It works on a competitor's site you want to learn from, on a site in an agency's portfolio you are evaluating, on an inherited site you want to understand, and as a pre-launch checklist on a build you are about to accept from your own agency.

• Page-builder div soup in the rendered HTML. Right-click the page and select View Source. Search for the class prefixes elementor-, vc_, or et_pb_. A heavy presence means a page builder is doing the layout. According to the 2025 Web Almanac CMS chapter, Elementor remains the most widely used WordPress page builder at roughly 43 percent of WordPress sites that use a builder, down from about 56 percent in 2024. WPBakery dropped to 13 percent, Divi to 10 percent, and the native WordPress block editor itself has grown to around 18 percent. The most common setup on WordPress sites is moving away from commercial-theme-plus-builder stacks toward native block-based builds. A site built with a custom block theme will not show these page-builder class prefixes at all.
• Stock theme detection. In the same view-source, search for wp-content/themes/. The folder name that follows is the active theme. Names like Astra, OceanWP, Hello Elementor, GeneratePress, and Divi as a theme indicate a commercial theme used as-is. That is not automatically disqualifying, but it does mean the build is template-plus-content rather than bespoke, and the buyer should price that in.
• Plugin path leakage in the network tab. Open the browser developer tools, switch to the Network tab, reload the page, and filter by wp-content/plugins/. Each distinct plugin folder you see is a plugin loading code on the front end. Twenty or more is the inflection point where update burden and attack surface compound. A serious build keeps this number low and uses front-end-only assets sparingly.
• Core Web Vitals field data. The three Core Web Vitals metrics (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift) measure how quickly and smoothly a page becomes usable for real visitors. Run the public URL through PageSpeed Insights and look at the CrUX badge, which is Google's real-user field dataset and reports the experience of actual Chrome users rather than a synthetic test. The 2025 Web Almanac records the median WordPress site achieving a 45 percent mobile Core Web Vitals pass rate, with a median Lighthouse performance score of 41 on mobile. That places the typical WordPress site below the "good" threshold. A professional build should show "Good" on all three Core Web Vitals at the 75th percentile of CrUX data within sixty days of launch.
• HTTPS, mixed content, and HSTS. Open the browser console on the homepage. Mixed-content warnings, certificate errors, or an HTTP-only login URL are smoke alarms. Failing this check in 2026 indicates the build was never put through a launch checklist.
• Login enumeration on /wp-admin/. Visit the login page and submit a fake username. If the response message tells you whether the username exists, the build is leaking enumeration to anyone with a browser. A hardened build returns the same generic message regardless of whether the account exists.
• Schema markup presence. In view-source, search for application/ld+json. The presence of JSON-LD blocks indicates the build did at least baseline SEO foundation work. The absence indicates nobody addressed structured data, which has knock-on effects for both classic search ranking and AI assistant citation.
• Third-party scripts firing before consent. Open the developer tools Network tab in an incognito window, then load the homepage without interacting with the cookie banner. If you see requests to Google Analytics, Meta Pixel, or any other tracking endpoint before you have accepted the banner, the site is not compliant with the European consent regime regardless of what the banner displays.

A site that passes six or seven of these eight checks is in good shape. A site that fails four or more is carrying quality debt that will surface as security incidents, performance complaints, or rebuild cost within the first two years. The audit takes fifteen minutes and does not require any privileged access. Use it before you ever talk to the agency that built the site.

Stage 2: the questions to put to any WordPress agency before signing

Stage 1 tells you what a finished build looks like. Stage 2 tells you whether the agency in front of you is likely to deliver one. The seven questions below are the ones a serious agency answers quickly and specifically. Vague or evasive answers on these questions are not a personality difference. They describe an agency that has not yet decided how it will build your site.

• Will the theme be custom, a child theme, or a commercial theme used as-is? A strong answer sounds like "we will build a custom block theme matched to your design, no page builder, and you will own the codebase". A weak answer sounds like "we will use Astra with Elementor and customize from there". Neither answer is wrong as such, but they describe very different products. A buyer who hears the second answer should understand they are buying a configured template, not a custom build, and price the work accordingly.
• How many plugins will the site ship with at launch, and can you list them with vendor names? A strong answer is a specific count below 15 to 20, with named reputable vendors and a one-line justification for each. A weak answer is "whatever we need" or a count above 30. Declining to commit to a number before discovery is acceptable, but the count needs to be on the table before launch, because it shapes your security exposure, your update burden, and your annual license cost for the next several years.
• What is your hardening checklist at launch, and is it documented? A strong answer references the WordPress.org Hardening guide as the floor, and names the agency's specific additions: two-factor authentication on /wp-admin/, file editing disabled in the dashboard with DISALLOW_FILE_EDIT, file permissions set to 755 for directories and 644 for files, a restricted database user, and the admin username never created. A weak answer is "our security plugin handles it". A security plugin can help once the floor is in place, but it does not stand in for the floor itself.
• Is staging on a separate URL, and will I have access to it throughout the build? A strong answer is a dedicated staging URL, behind basic authentication, indexed nowhere, with the buyer having read access from week one and the agency deploying to production from staging on a defined cadence. A weak answer is "we work directly on production" or "we will send you screenshots". Working directly on production is what happens when no real workflow has been set up for the project.
• What Core Web Vitals scores will the site ship with, measured on the live URL? A strong answer is a written commitment, for example "Good on LCP, INP, and CLS at the 75th percentile of CrUX field data within sixty days of launch", with a remediation clause if the commitment is missed. A weak answer is "fast enough" or "we will optimize after launch". Optimization left for after launch usually gets quoted as a separate engagement, and in many cases it does not happen at all.
• What accessibility standard do you build to, and will I get a pre-launch audit report? A strong answer is "we target WCAG 2.2 Level AA, we run an automated scan plus a manual keyboard and screen-reader pass, and you receive the written report at handover". WCAG 2.2 Level AA is the international web-accessibility standard that most public-sector and large-corporate sites apply as their baseline, and the practical target for any serious site in 2026. A weak answer is "WordPress is accessible by default", which does not survive any real audit. According to the WebAIM Million 2026 report, the average WordPress home page carries 52.8 detectable WCAG errors, which places the platform mid-pack against Drupal at 41.2 and Wix at 33.3. Whatever accessibility work the WordPress project does on the platform itself only transfers to your site if your build was made with accessibility in mind from the start.
• Where will backups go, and will you run a restore drill before handover? A strong answer is "daily off-site backups to a named provider, 30-day retention minimum, and a restore drill to staging in the final week of the build with a screenshot you can keep". A weak answer is "there is a backup plugin". A backup that has never been restored is an assumption rather than a backup, and most of the time the gap shows up during a real incident, when there is no longer any margin to fix it.

The three highest-signal questions on this list are theme strategy, plugin inventory, and the hardening checklist. A buyer should not sign a build contract without clear answers to those three, because they describe the foundation of the site they will be paying to maintain for the next five years. The other four can be negotiated later if needed.

Stage 3: Demand specific proof at handover

Handover is the moment where the agency hands the keys to the client and the client accepts the work. It is also the moment where most quality compromises become permanent, because they get rolled into "the site is live, let us move on". The way to prevent that is to make handover evidence-based: every claim the agency made at kickoff produces a specific artifact at handover, and the site is not accepted until those artifacts are delivered.

• A pre-launch accessibility audit report. Automated scan results plus the manual review notes, dated within the final week of the build. The report should name the standard targeted (WCAG 2.2 Level AA is the current default), the scope of pages tested, the tooling used, and the issues found with their resolutions. A zero-error automated scan is a floor, not a ceiling. Automated tools catch a fraction of real accessibility failures, and a clean automated scan with no manual review attached is a signal of incomplete work.
• A restore-drill screenshot to staging. Proof that the backup pipeline was tested end to end, not just configured. The screenshot should show staging running the restored snapshot, dated, with the timestamp of the source backup visible. Without that screenshot, the backup remains theoretical rather than verified.
• A complete plugin inventory. A CSV or markdown table listing every plugin shipping at launch, with vendor name, plugin URL, license type, annual renewal cost, and renewal date. This lets the buyer plan the annual budget and lets a future maintainer audit the attack surface without re-discovering what is installed. It also makes plugin abandonment visible: a plugin whose last update was more than a year ago is on a path to becoming a vulnerability.
• Owner-level access to the code repository. The site code should live in a Git repository on GitHub, GitLab, or an equivalent host, with the buyer as the account owner, not as a collaborator. If the code lives "internally" at the agency, the buyer is locked in even if the contract says otherwise. Owner access stays with the buyer no matter what happens to the relationship, whereas collaborator access can be revoked by the account holder at any moment.
• The hardening checklist as a deployed document. Not "we apply our security checklist" in the abstract, but the specific list of items applied to this specific site, dated, with the values in place where relevant (file permissions, database user privileges, two-factor configuration, the DISALLOW_FILE_EDIT setting, and so on). The checklist becomes the basis for any future audit, including ones conducted by a different agency.
• An environment and deploy procedure document. Where staging and production live, who hosts them, what the deploy command looks like, who holds SSH keys, where DNS is managed, where backups are stored, and where logs are accessible. This document is what makes the site portable. A site without it is portable only by the agency that built it, which is another kind of lock-in.
• A defined warranty period in the contract. Typically 30 to 90 days post-launch, covering bug fixes against the agreed specification at no extra charge. A warranty covers a different scope than a maintenance contract: it is a promise that what was delivered matches what was specified, fixed at no extra cost during the warranty window. An agency that offers no warranty at all, or that wants every change billable from day one, is telling the buyer how the relationship will work over the long term.

Any single artifact missing at handover can usually be recovered with a follow-up email. Three or more missing means the build is incomplete and the agency is asking the buyer to accept it anyway. The way to keep that conversation from happening at delivery is to name these artifacts in the kickoff and reference them in the contract.

AI and agent readiness

One layer of build quality is hard to ignore in 2026 and almost entirely absent from existing WordPress checklists: whether the site can be read, understood, and cited by AI assistants. A growing share of visitor traffic now passes through AI systems that summarize content before the visitor ever sees it, and the sites those assistants quote get visibility that the sites they overlook do not. We cover the topic in depth in our guide on getting your website ready for AI agents. The minimum a serious WordPress build should ship with is the following six items.

• Semantic HTML and a clean heading hierarchy. One H1 per page, H2s for top-level sections, no skipped levels. AI systems parse document structure before they parse content. A site that opens with three H1s and skips from H2 to H4 is being read as three separate documents stitched together.
• FAQPage and Article schema as a baseline. These two schema types account for the majority of AI-cited content snippets in current monitoring. They are inexpensive to add and have measurable effect on citation frequency.
• Correct canonical and hreflang where the site is multilingual. Wrong canonicals cause AI systems to cite the wrong page. Missing hreflang causes the assistant to pick the wrong language version when answering a query in either language. Both are common on multilingual WordPress sites and both are checkable in view-source.
• A public Organization entity with sameAs. JSON-LD on the homepage describing the organization and linking to its authoritative profiles: LinkedIn, GitHub, Crunchbase, the local business register where relevant. This is how AI assistants resolve "who is this?" reliably enough to cite the source.
• Primary content not rendered exclusively in JavaScript. Many AI crawlers either do not execute JavaScript at all or pass the page through a rendering queue that adds meaningful delay, much as Google itself documents for the rendering behavior of its own crawler. Content that only appears after a script runs is content that may not appear in AI training data at all.
• An optional /llms.txt file. The convention for agent-readable site summaries is still emerging, but the cost of adding the file is trivial and the signal it sends to AI operators is that the site author is paying attention to this channel.

Frequently asked questions

What does a professional WordPress website build include?

A professional WordPress build ships with a custom or carefully chosen block theme, a tight plugin estate from reputable vendors, the WordPress.org hardening checklist applied as the floor, Core Web Vitals at "Good" on the live URL at launch, a pre-launch accessibility audit against WCAG 2.2 Level AA, daily off-site backups with a tested restore, a separate staging environment, the site code in version control the buyer owns, full handover documentation including a plugin inventory and a deploy procedure, and a defined warranty period in the contract.

How do I know if a WordPress agency does quality work?

Look at three things together. First, a live site they have built that passes the Stage 1 audit in this article: clean view-source, "Good" Core Web Vitals, no plugin path leakage, no enumeration on the login. Second, clear written answers to the Stage 2 questions, especially on theme strategy, plugin inventory, and the hardening checklist. Third, the Stage 3 handover artifacts named on the proposal in writing, not vaguely promised somewhere toward the end. An agency that does quality work tends to describe that work in concrete terms, with reference to live sites, named processes, and named deliverables.

What is the difference between a cheap WordPress site and a professional one?

The structural differences are visible at every stage. A cheap WordPress site typically uses a commercial theme stacked with a heavy page builder and thirty or more plugins, deployed without hardening, without accessibility work, without a separate staging environment, and without documentation. A professional WordPress site uses a custom or carefully chosen block theme, a tight and justified plugin list, a hardened launch, measurable performance and accessibility, and a clean handover the buyer can take to any future maintainer. Hosting costs are similar between the two. The build cost is where the difference lives.

How much does a properly built WordPress website cost?

The headline price is rarely where the meaningful variation lives. Two sites with the same brief and the same feature list can differ by an order of magnitude in total cost depending on how the theme is built, how disciplined the plugin selection is, and how much engineering work goes into security, performance, and accessibility before launch. A cheap build usually reuses a commercial theme stacked with a heavy page builder and stops at configuration, while a professional build spends engineering hours on the dimensions described in this article. The headline difference between the two is rarely about the feature list, and almost always about the care that went into every layer of the build.

How can I check the quality of a WordPress site before hiring the agency that built it?

Run the Stage 1 audit on a live site from the agency's portfolio. View-source for page-builder class prefixes and the active theme name. Run PageSpeed Insights and check the CrUX field data badge. Check for JSON-LD schema markup in view-source. Count plugin paths in the developer tools Network tab. Verify the login page does not leak username enumeration. Fifteen minutes of work on a live URL tells you more about how the agency builds than any sales call will.

Where this fits in your decision

This article assumes you have already chosen WordPress. If you are still weighing platforms, our platform audit framework covers the five checks that decide whether WordPress is the right platform for your project. If you are upstream of agency selection and putting together a brief, our guide to preparing a web project for an agency covers what to bring to the table. And once the build is live, the operational rules change: our guide to WordPress maintenance contracts covers what the agency should be doing for you from launch onward.

If you want an independent perspective on a WordPress site you are about to commission, or on one you have inherited and need to evaluate, our consulting and advisory service is built for exactly this. If you want a team to deliver a build against the standards in this article, our web development service starts from the same checklist.

Keroberos is a web technology consultancy that advises businesses on platform selection, commissions and delivers WordPress and Drupal builds, and provides staff augmentation for development teams. To discuss your WordPress project, contact us.