Provisioning, for an agency running an operating layer, is the act of wiring a new site into the accumulated context of your entire fleet before the first client conversation begins. The traditional definition covered server setup: domain, hosting, database, WordPress install. That sequence still runs. But for agencies operating a fleet, provisioning now has a second layer that matters more to long-term delivery than the server choice does.

Before anyone opens a page editor or picks a color palette, the site needs to exist inside the operating system. Three things are in place before the work starts:

• The Playbook for this client is open and pre-populated with what you already know: industry, audience, and decisions from comparable clients in the fleet.
• The branding kit is configured so every output from this point forward reflects the client’s identity, not a generic default.
• The site is visible in the Workspace alongside the rest of the fleet, so pattern detection runs from day one rather than being retrofitted after launch.

Agencies that skip this step spend the first month building institutional knowledge that should have arrived on day zero. The ones that run a deliberate provisioning sequence find the site operating at full capacity weeks earlier, and the compounding effect of the Playbook kicks in from the first conversation rather than the tenth.

The Playbook entries you write before launch are the most valuable ones you will ever write for this client, because every subsequent entry references them. The Playbook’s Brand and Audience chapters are not post-launch documentation; they are provisioning inputs that shape every command the site agent runs from the first session.

Here is what to populate before the WordPress install is complete:

• Brand chapter: Client name, primary and secondary colors, typefaces, and tone notes (formal, conversational, or technical), plus anything from the brief or discovery call that would otherwise sit in a document and get lost after the project lead rotates off the account.
• Audience chapter: Who the client’s site serves, primary geographic markets, and any audience language that differs from the client’s own. This is what prevents the site agent from defaulting to generic copy on the first task.
• Decisions log: Log the decisions made during the sales or discovery phase. A note like Client requested no e-commerce now but wants WooCommerce-ready architecture is a Playbook entry, not a message in a chat thread that will scroll out of reach within three weeks.
• Internal chapter: Which team member owns this site, the contact cadence, and the billing structure. Context that matters to operations but is never client-facing.

Populating these four areas before launch means the first time anyone opens the Command Center for this site, they are working with a fully contextualised operating layer rather than a blank screen.

A branding kit configured before the first commit ensures every asset the operating layer produces for this client is consistent, without a team member checking it manually on every pass. The branding kit lives inside the Command Center and ties directly to the Playbook’s Brand chapter, so the two stay in sync as the engagement develops.

Three inputs are required at provisioning:

1. Primary hex values: Enter the client’s brand colors. If the brief includes a full palette, add secondary and tertiary colors now so the operating layer never defaults to arbitrary choices.
2. Tone directive: One sentence describing how the site agent should communicate on behalf of this client. Make it specific: not professional but direct, evidence-first, addressed to procurement leads at mid-market SaaS companies. This single sentence is the highest-return input in the provisioning process.
3. Vocabulary controls: Add the terms the client uses specifically and the terms they have asked to avoid. Brand language they expect to see, and competitor language that is off-limits.

This configuration takes under ten minutes at provisioning. Skipping it means correcting outputs manually every week for the lifetime of the engagement, because every generated draft will require a tone pass that the branding kit would have made automatic.

Adding the new site to your fleet in the Workspace is what activates fleet-level pattern detection; until the site is there, the operating layer cannot compare it against your other sites or surface cross-client patterns that reveal risk before clients see it. Once the WordPress install is live, add it as a new site from the Workspace and install the Command Center from wp-admin. From that point, the site is part of the fleet.

For agencies already managing multiple WordPress sites, a fleet-wide view of site health becomes the primary way to catch drift before clients notice it and the primary source of the pattern detection that makes the operating layer compound in value across every client engagement.

Two things to confirm at connection:

• Site status: Set it correctly in the Workspace: In Development, Live, or Maintenance. This determines how pattern detection scores the site and what the site agent flags as requiring attention.
• Fleet-wide Connectors: Any Connectors that apply across the entire fleet (your project management platform, your reporting stack) are inherited by the new site automatically. Client-specific Connectors require a separate step covered in the next section.

At this point the site is in the fleet. It is not yet fully operating. The Playbook has context, the branding kit is active, and the site is visible in the Workspace. What remains is client-specific Connector and Skills configuration.

The Connectors and Skills you configure in the first week determine how much of the agency’s existing stack this site operates within, and how much manual handoff remains between the operating layer and the client’s own systems. WPOS connects to over 1,000 external services. Not all of them apply to every client. The provisioning task is to identify and activate the ones that do.

Priority Connectors for a new client site:

• CRM: If the client manages leads through a CRM, wire it in at provisioning. This lets the site agent surface contact context during content and WordPress maintenance tasks without requiring a team member to switch platforms to check it.
• Project management: Connect your agency’s project management platform so tasks created in the Command Center appear in the same queue as the rest of your delivery work. This is a fleet-wide Connector for most agencies; confirm it is active for the new site.
• Analytics: Wire in the client’s analytics account so site status reporting draws on real traffic data, not just uptime. A site the client considers performing well deserves a Playbook entry logging why.

For Skills, review the agency Playbook library and activate the ones relevant to this client’s vertical. A Content Review skill built for a similar client last quarter may apply directly here. The Skills library compounds in value across the fleet the more consistently it is applied at provisioning rather than added mid-engagement under delivery pressure.

The first week is the highest-return configuration window: the Playbook is fresh, the client is engaged, and corrections to context cost minutes rather than months of compounding misalignment. A structured sequence keeps the provisioning work from getting absorbed by delivery pressure before it is complete.

Days 1 and 2: Complete the pre-provision Playbook entries across the Brand, Audience, Decisions, and Internal chapters. Configure the branding kit with colors, tone directive, and vocabulary controls. Add the site to the Workspace fleet and set the correct status.

Day 3: Activate fleet-wide Connectors and confirm they are running for the new site. Add client-specific Connectors for the CRM, analytics platform, and any service the client manages directly. Assign Skills from the agency Playbook library.

Days 4 and 5: Run the first Command Center session for this site. The site agent’s first responses will draw on the Playbook context you set on day one. Correct anything that is wrong immediately: early Playbook corrections carry the greatest return because they prevent an error from compounding across every subsequent session. Log the corrections back to the Decisions chapter.

By the end of week one, the site is operating. The Workspace shows it in the fleet with the correct status. The Playbook holds a minimum of seven entries. The branding kit is producing consistent outputs. Review the current plan tiers to confirm your fleet size and Skills capacity for this client.

The WPOS provisioning sequence separates client-facing access from agency-level context, so you hand the client a site they can operate without exposing the operational layer your agency built over months of delivery. This is one of the structural advantages of running an operating layer over running a collection of individual sites: the institutional knowledge is in the system, not the personnel.

Traditional agency handoffs carry a hidden cost. The project lead knows why the template is structured a certain way. The account manager remembers what the client rejected in discovery. When those people move to other accounts or leave the agency, that context goes with them. Every new person who picks up the site starts the same reconstruction process. The context cost compounds quietly.

The WPOS provisioning sequence builds differently. The Decisions chapter logs why choices were made. The Internal chapter holds team context. The Conversations chapter preserves the reasoning behind major calls. None of that is visible to the client in normal operation. What the client sees, if you extend them access, is the Command Center for their site: the operational view of their site’s health, the branding kit, and the ability to log their own requests.

Guest agent access lets a client interact with the site agent without seeing the agency’s fleet structure, Playbook architecture, or Skills library. The handoff gives them operational capability. It does not export your operating system. That distinction compounds in value every month you run the engagement: six months in, the Playbook holds context no individual person carries. At twelve months, it holds context no individual person could carry.

A standard agency handoff delivers everything a developer needs to log in and nothing they need to understand what they are inheriting. The package looks complete: admin credentials, hosting panel access, a Git repository, maybe a Notion doc with environment details. It checks the boxes the client signed off on. What it does not transfer is the reasoning layer behind months of decisions.

The new developer will find a custom post type with no explanation of the editorial requirements that shaped it. They will find a child theme override with no note about the accessibility complaint that prompted it. They will find a plugin deactivated in staging with no record of why it was pulled. They will find a field group that looks redundant but is not, because the client’s internal team writes to it via a CSV import the agency set up and then forgot to document.

A credential drop is a file transfer disguised as a handoff. The files survive. The context does not. For agencies running multiple active client sites, the cumulative cost of that missing context is not a single re-investigation. It is a tax paid on every new ticket, every new hire, every account transition.

Files are version-controlled; decisions are not, and that asymmetry is where institutional knowledge goes to die. Git tracks every line change with precision. It does not track whether a change was made to satisfy a client requirement, to work around a third-party bug, or because the developer running the sprint that week had a strong personal preference.

The decisions gap is not a documentation failure. It is a structural problem: the systems agencies use for delivery (version control, project management, team chat) are optimized for the moment of execution, not for the moment of retrieval months later when a new person needs to understand why the site is shaped the way it is.

Three categories of context consistently disappear at handoff. First: architectural decisions and what was rejected. Second: client-specific constraints (things the client will not change, stakeholders who must approve certain work, known sensitivities). Third: operational quirks specific to the environment, hosting configuration, or integrated services. These do not live anywhere because nobody built a place for them. They live in the head of the developer who built the site, and when that developer transitions off, they leave.

A complete WordPress agency client handoff checklist separates three layers: access, configuration, and context. Most agency offboarding processes cover the first two and skip the third. The third is the only one that degrades with time.

Access layer

• WordPress admin credentials and role assignments
• Hosting control panel access (cPanel, Kinsta, WP Engine, Cloudways, etc.)
• DNS registrar and nameserver credentials
• All third-party service accounts tied to the site: email provider, payment gateway, analytics, CDN
• SSH keys and SFTP credentials
• Git repository access and branch conventions

Configuration layer

• Active plugins with a one-line rationale for each (not just “WooCommerce” but “WooCommerce: powers the membership checkout, client owns the license”)
• Theme and child theme decisions, including what the parent theme was chosen over and why
• Custom post types, taxonomies, and field groups with their editorial purpose
• Cron jobs and scheduled tasks running on the server
• Staging environment setup and the promotion process to production

Context layer

• Major architectural decisions and the alternatives that were considered
• Known client preferences and constraints: what they will and will not approve
• Stakeholder map: who owns approvals, who is the day-to-day contact, who has final say on design changes
• Ongoing issues, known bugs, or work that was descoped and may resurface
• Performance baselines and monitoring setup

The context layer takes the most time to write and creates the most value. It is also the layer that disappears if nobody makes it a delivery requirement, not a best-effort addition.

The problem with shared drives and Notion pages as a decision repository is that nobody knows to look there when they inherit a site. The agency knowledge transfer template matters less than where that knowledge is stored relative to the site itself.

Decisions need to live in a place with three properties: attached to the site (not to a person or a folder inside someone’s workspace), persistent across team changes, and accessible at the moment work begins rather than requiring a separate lookup step. When decision records live inside the operating layer of the site, a new developer does not need to know to find them. They encounter them as part of operating the site.

This is the principle behind the Decisions log and Playbook that WPOS maintains per site inside the WordPress Command Center. Every significant decision made through the site agent gets recorded with its context: what was decided, what was considered, what the client required. A developer joining six months later is not starting from the repository history. They are starting from the site’s accumulated record.

Even without a purpose-built operating system, the discipline holds. Wherever decisions live, they must be attached to the site as an artifact, not to the person who made them. The handoff process should verify that record exists and is current before anyone signs off.

The 30 days after a handoff are when knowledge gaps become visible, and the agency that surfaces them first keeps the relationship. Waiting for the incoming team or client to surface problems is a reactive posture that costs more to recover from than it saves in the short term.

Week 1: Monitor incoming questions. Every question the new developer or client team asks is a signal. Questions like “why is this function here” or “what does this field do” indicate documentation gaps. Log them. They become the first draft of what needs to be added to the site’s context record.

Week 2: Check performance and error baselines. Compare uptime, page speed, and PHP error logs against the pre-handoff baseline. A site that was healthy before the handoff should be healthy after. Any regression points to a configuration that was changed without understanding its role.

Week 3: Structured debrief. A 30-minute call with the incoming developer surfaces the reverse-engineering they had to do. What did they have to figure out themselves that should have been documented? This is the fastest way to close the gap between what the handoff covered and what the site actually requires.

Week 4: Close the record. Add every gap surfaced in the first three weeks to the site’s context record. Update the decisions log. The audit is not complete until the site’s operating layer reflects what the team now knows.

Agencies that run this audit consistently find the same two or three gap categories repeating across clients. That pattern becomes the input for updating the handoff checklist so the same gaps do not survive the next transition.

Agencies that document decisions during delivery, not at handoff time, never have to sprint to fill the context gap at the end of a project. The cultural shift is treating context capture as a byproduct of doing the work, not as a cleanup task assigned to whoever is leaving.

In practice this means three things. First: every significant decision made during a project gets a brief explanation recorded at the time it is made. Not a long memo, one or two sentences about what was decided and why. Second: handoffs become a verification pass rather than a documentation sprint. The team checks that the record is current rather than writing it from scratch under deadline pressure. Third: new team members onboard from the site’s record rather than from a departing developer’s memory.

Agencies running their fleet on an operating system like WPOS find that the Playbook per site already carries months of decision history. The incoming developer is not starting cold. They are reading the site’s operating history from day one.

The checklist and the audit are starting points. The compounding advantage goes to agencies that make context capture a standing part of how they operate every site from the moment it is provisioned, not a heroic effort at the end of every project.

WordPress Playground is a browser-native WordPress environment that runs entirely in WebAssembly, giving agency operators a disposable, zero-setup instance in under 10 seconds. No server provisioning, no teardown, no cost to spin up or discard.

The environment supports full WordPress functionality: installing themes and plugins, running the block editor, submitting forms, and hitting REST API endpoints. You can configure the WordPress core version and PHP version independently, which means you can match the exact production stack of any client site in your fleet.

For agencies operating dozens or hundreds of client sites, this changes the economics of update testing. Rather than maintaining a staging environment for every client, you spin up a disposable replica, run your checks, and discard it. The replica matches the client’s stack, the test runs in minutes, and the instance disappears when you close the browser tab.

The practical scope of what you can test includes: core update regressions, plugin compatibility with a new core version, theme rendering after a PHP upgrade, and REST API contract changes that affect third-party connections. What Playground does not replicate perfectly is server-level configuration and live database state, so for checks that depend on real client content, import a recent export from production.

The WordPress 7.0 release demonstrated that even a well-tested core update can introduce regressions that only surface in specific plugin and theme combinations. The keyboard navigation regression in the block editor was not a fringe case; it affected a broad range of installations and was caught by end users before many agencies caught it in a testing environment.

The agencies that handled it cleanly had a pre-flight process. They ran the update in a Playground instance, opened the block editor, and navigated with a keyboard within the first two minutes of testing. The regression was obvious and immediate. They held the update until a patch landed, and their clients never saw it.

The agencies that scrambled had pushed the update fleet-wide first. Recovery meant logging into each affected site, manually reverting or patching, and fielding client support tickets in the meantime. The cost was measured in hours per site, multiplied across the fleet.

The lesson is not that WordPress core updates are unreliable. The lesson is that production environments are more varied than any single test environment, and an operating layer that catches regressions before they reach clients is not optional for agencies at scale. The pre-flight step is that operating layer.

Spinning up a Playground instance that mirrors production requires three configuration decisions: WordPress core version, PHP version, and plugin set. Get these three right and the instance behaves like the client’s site for purposes of update testing.

The browser-based launcher at playground.wordpress.net is the fastest starting point. Select the WordPress version from the version picker, set the PHP version to match production, and install the plugins the client runs. Activate the client’s theme. For any check that depends on real content, use the WordPress export tool on the live site, then import the XML file into the Playground instance using the WordPress importer plugin.

A few practical notes on accurate setup:

• Match the PHP version exactly. A PHP 8.1 site behaves differently from a PHP 8.3 site under a new core version, and a regression may only surface on one.
• Install plugins in the same activation state as production. A deactivated plugin can still affect behavior if its database tables are present.
• Enable WP_DEBUG and WP_DEBUG_LOG. Core updates sometimes introduce PHP notices that are silent in production but signal future compatibility problems.
• If the client uses a child theme, install the parent theme first and activate the child theme over it.

Setup takes three to five minutes for a typical site. For complex sites with many plugins or custom post type structures, budget ten minutes to replicate the full stack accurately.

The WordPress Playground CLI turns a one-time manual setup into a scripted, repeatable launch that any operator on your team can run in a single command. It is available to download as an npm package (@wp-playground/cli) and runs locally without a server, making it practical to incorporate into any agency’s operating environment.

The core concept is the blueprint: a JSON file that declares the WordPress version, PHP version, plugins to install, and any setup steps to run on first boot. A blueprint for a client’s site specifies their exact stack and can include a step to import a content export file. Storing a blueprint per client in your repository means the Playground instance for that client is always one command away: npx @wp-playground/cli server u002du002dblueprint=blueprint.json.

Additional CLI capabilities that matter for pre-flight work:

• The u002du002dmount flag maps a local directory into the instance, useful for testing a theme or plugin under active development before it is pushed to any live site.
• The run-php command executes PHP scripts directly against the Playground instance, which is useful for verifying that custom update routines behave correctly under the new core version before they touch live data.
• The CLI accepts blueprint files as URLs, so a team can maintain a shared blueprint repository and reference blueprints by URL across operators.

For agencies running a large fleet, the CLI can be incorporated into a CI pipeline so that a Playground instance spins up, runs checks via WP-CLI commands, and reports a pass or fail result automatically on each core release.

A thorough pre-flight check covers three areas: the block editor and admin experience, front-end rendering, and any third-party connections the site depends on. Running all three takes 15 to 30 minutes per site configuration and catches the majority of regressions before they reach production.

Admin experience checks:

• Open the block editor on a post with a complex layout and navigate between blocks using the keyboard. This is where the WordPress 7.0 regression surfaced in under two minutes.
• Save a post, a page, and a widget area. Confirm the save succeeds and the changes appear on the front end.
• Open each plugin’s settings page and confirm it loads without a PHP error or a blank screen.
• Test any admin-side form that writes to the database: custom fields, option pages, meta boxes.

Front-end rendering checks:

• Load the homepage, a category archive, and a single post. Confirm the theme renders without PHP notices visible in debug mode.
• If the site uses a page builder, open a template built with it and confirm the layout is intact.
• Test any JavaScript-dependent feature: sliders, accordions, AJAX search, infinite scroll.

Third-party connection checks:

• Submit any form that connects to an external service and confirm the submission processes correctly.
• If the site exposes a REST API endpoint that another system consumes, request that endpoint and verify the response structure has not changed.
• If the site uses a caching plugin, flush the cache and reload to confirm no stale markup is served.

Document this checklist in a shared runbook so every operator on your team runs the same checks in the same order. Consistency is what makes the pre-flight reliable across a fleet.

Whether to update core or plugins first is not a general rule; it is a decision made in the context of each release, and the Playground environment is where you make it safely. Testing core first against the existing plugin set isolates any core-specific regression. If core passes, updating plugins one at a time (or in logical batches) means that when a regression appears, you know exactly which update introduced it.

The practical sequence for most major core releases:

1. Spin up a Playground instance on the current core version with all client plugins active and confirm the baseline is clean.
2. Update core to the new version. Run the full pre-flight checklist.
3. If core passes, update plugins one at a time in order of risk: security-critical first, then active plugins, then inactive ones. Run a focused check after each update.
4. If a plugin update introduces a regression, you have isolated the cause before anything reached a live site.

For minor core updates and security releases, the sequencing can be abbreviated. Security patches carry lower regression risk and can be tested with a focused check rather than the full checklist. Major releases warrant the full sequence every time.

For a deeper treatment of sequencing strategy across a client fleet, including how to group sites by risk tier, see how agencies should sequence WordPress core and plugin updates across a client fleet.

A pre-flight check only compounds value when it is written into a runbook and attached to your update process as a non-negotiable gate. A check that depends on one person remembering to run it is not a process; it is a habit, and habits fail under pressure.

The minimum viable runbook for a Playground pre-flight has four components:

1. Blueprint file location: Where to find the client’s blueprint file, or the steps to create one if you have not yet scripted it.
2. Setup steps: How to launch the instance, which content export to import, and how to confirm the environment matches production.
3. Check list: The specific admin, front-end, and third-party connection checks to run, in order, with the expected result for each.
4. Gate criteria: What constitutes a pass (all checks clear) and what constitutes a hold (any check fails, the update does not proceed to any site in the fleet).

When the runbook is the artifact, the pre-flight step survives team changes, onboarding, and high-pressure release cycles. New operators follow the same process as experienced ones. The agency’s operating layer for updates is consistent regardless of who is running it on a given week.

For agencies operating at scale, this runbook becomes a standing Playbook in how the team manages every core release cycle. The Playground instance is the proving ground; the runbook is what makes that proving ground mandatory. Together, they form the part of the agency’s operating system that protects clients from regressions before a single production site is touched.

Most WordPress speed optimization guides solve for one site at a time. Install a caching plugin, run a PageSpeed Insights test, optimize a few images, and move on. That approach works when you are responsible for one property. It does not work when you are operating dozens or hundreds of client sites and need to allocate a finite team’s time to the places where it produces the most impact.

The fleet operator’s problem is not which WordPress performance optimization plugin to install. It is how to know which sites need attention, in what order, and why, before opening a single admin panel. Without a systematic baseline, performance work becomes reactive: you fix the site whose client complained most recently, not the site whose users are actually suffering. That pattern produces a series of fire drills rather than a compounding service.

This post builds the operating model for fleet-scale performance audits: how to measure uniformly, what to measure, how to triage the results, and how to repeat the process often enough that improvements accumulate rather than decay.

You cannot triage what you have not measured, so the first move in any fleet performance audit is establishing a uniform baseline across every site. Pick the same representative pages for every client: the homepage, one interior content or product page, and one conversion page (contact, checkout, or lead form). Run the same set of tests against those pages and record the results in a format you can sort and compare across sites.

The baseline serves two purposes. First, it tells you where the fleet stands right now so you can rank sites by severity. Second, it gives you a reference point so that future measurements reflect actual changes in the sites, not variations in how you measured. Without a baseline, every performance conversation with a client starts from scratch. With one, you can show the delta between where the site was and where it is now, which is far more useful than a raw score in isolation.

For agencies running many sites, a scripted Lighthouse CLI run against a maintained URL list is the most practical way to produce uniform lab data at scale. Run it from a consistent environment (a cloud VM, not a developer laptop on a home network) so results are comparable across time. Pair the lab data with a review of Google Search Console’s Core Web Vitals report for sites with enough real-user traffic to generate field data. The combination of lab and field measurements covers both what you can assess on demand and what real users are actually experiencing on varying devices and connection speeds.

Core Web Vitals, TTFB, and total asset load together cover the full diagnostic space of WordPress performance problems at fleet scale. Each metric surfaces a different category of failure, so you can identify the root cause class before deciding what to fix, without needing to dig deep into any individual site during the triage phase.

• Largest Contentful Paint (LCP): Measures when the main content of a page becomes visible to a user. Google’s passing threshold is 2.5 seconds. LCP failures trace to slow server response, unoptimized images, or render-blocking resources. It is the single most actionable metric for fleet triage because its root causes are well-defined and its threshold is clear.
• Cumulative Layout Shift (CLS): Measures visual instability as a page loads. A CLS score above 0.1 is a concern; above 0.25 is a failing grade. Common causes in WordPress fleets include images without declared dimensions and ads or embeds that load asynchronously after the surrounding content has already rendered.
• Time to First Byte (TTFB): Measures how long the server takes to deliver the first byte of a response. TTFB above 800 milliseconds is a signal to investigate the hosting environment, PHP execution time, database query load, and page caching configuration before touching any front-end asset.
• Total asset load: The combined weight of JavaScript, CSS, and images on the page. Heavy asset load points to front-end problems: unoptimized images, bloated theme dependencies, or plugins adding scripts on every page regardless of whether those scripts are used on that page.

Measuring all four at baseline lets you classify each site’s primary failure mode before opening any individual site. A site with high TTFB but reasonable asset load has a server-side problem. A site with fast TTFB but poor LCP usually has an image or render-blocking issue. That classification is what makes fleet triage tractable without requiring deep manual investigation per site.

Fleet-scale data collection is only sustainable if it runs with minimal manual intervention. The standard single-site approach of opening a browser tab, running a PageSpeed Insights test, and writing down a score does not survive contact with a 50-site fleet. You need a collection method that produces the same output format for every site, every time, and can be re-run on a schedule without someone coordinating it.

A practical fleet collection setup draws from three sources:

1. Scripted Lighthouse CLI runs against a maintained URL list. Run from a consistent cloud environment on a regular schedule and export results to a structured format (JSON or CSV) that you can sort and query. This is your primary lab data source.
2. Google Search Console Core Web Vitals reports for every client site that generates enough real-user traffic. This field data reflects actual user experience across devices and connection types, which lab data cannot replicate. Pull it monthly for every site that qualifies.
3. Lightweight TTFB checks using a simple HTTP timer or curl command. TTFB is cheap enough to measure daily across the full fleet and provides early warning of server-side regressions before they affect front-end scores.

One detail that matters more than most operators expect: run your Lighthouse tests from a consistent machine and network environment. Test results vary significantly between a developer’s laptop and a stable cloud VM. If your collection environment changes between runs, you cannot tell whether a score change reflects a change in the site or a change in how you measured it. Standardize the environment, document it in your runbook, and do not deviate from it.

The goal is not to collect every possible metric. It is to collect a small number of actionable metrics consistently, so that when a site degrades between measurement cycles, you see the change in the numbers before you hear about it in a client email.

With fleet-wide baseline data in hand, triage by impact before touching any individual site. Rank sites by their LCP score and cross-reference against business context: a failing score on a high-revenue e-commerce site is more urgent than the same score on a low-traffic informational site. Severity times business impact is a more defensible scheduling basis than the order in which clients raised concerns.

A practical triage framework for a 20-to-100 site fleet:

• Tier 1 (address within two weeks): Sites with LCP above 4 seconds, TTFB above 800ms, or CLS above 0.25. These are failing Google’s Core Web Vitals thresholds and are likely affecting both organic search rankings and user conversion rates.
• Tier 2 (address within the quarter): Sites that are passing minimums but trending toward failure, sites where total asset load has grown substantially since the last baseline, or sites where field data diverges meaningfully from lab data in a way that suggests real-user experience is worse than the score implies.
• Tier 3 (monitor and maintain): Sites passing all thresholds with stable scores. Track for regression on the standard cadence but do not schedule active remediation work.

Triage also shapes the conversation you have with each client. A Tier 1 site is a concrete, quantified problem: LCP at 5.2 seconds is in Google’s failing range, and that is a defensible reason to schedule remediation work. A Tier 3 site is a positive status update. Triage gives your team consistent, data-backed language for every client performance conversation, not a judgment call that has to be re-derived each time.

The same triage logic scales to any category of site health work. The approach described in running a general site audit across your client fleet follows identical principles: baseline uniformly, classify by severity, and sequence remediation by impact rather than by complaint volume.

Performance audits produce compounding returns only when they repeat on a schedule. A one-time audit tells you where the fleet stands today. A recurring audit tells you whether the fleet is improving, holding, or degrading, which is the information you need to make fleet-level decisions rather than site-level ones.

A practical cadence for most WordPress agencies:

• Monthly: Run a TTFB check across the fleet and flag any site that has regressed by more than 200 milliseconds since the previous month. TTFB regressions typically trace to a plugin update, database growth, or a hosting configuration change, and they are inexpensive to catch before they affect front-end scores.
• Quarterly: Run a full Core Web Vitals and asset load baseline. Compare against the previous quarter’s numbers. Any site that has degraded by more than 20 percent in LCP, or whose CLS score has moved into the failing range, goes into the remediation queue for the next sprint cycle. This is the most operationally important cycle: frequent enough to catch regressions before they become client problems, infrequent enough that it does not consume a disproportionate share of team capacity.
• Annually: Run a full performance audit alongside a broader site health review. Address Tier 2 sites, review whether your standard WordPress performance optimization service configuration is still current given WordPress core and major plugin changes, and update your runbook with patterns you encountered during the year.

When your fleet’s audit data, remediation records, and site notes live in a single operating layer, the quarterly review becomes a data exercise rather than a coordination exercise. You are reading numbers, not chasing context across emails and spreadsheets.

A documented runbook is what converts a one-time audit into a repeatable agency service. Without one, the audit lives in one person’s knowledge and requires that person to run it every time. With one, any trained team member can execute it consistently, record findings in the standard format, and contribute to the fleet record.

A performance audit runbook should specify:

• Which pages to test on each site type (e-commerce, brochure, membership, directory) and why those pages were chosen
• Which collection tools to use, how to run them, and how to record results in the standard output format
• The scoring rubric: exact thresholds for Tier 1, Tier 2, and Tier 3 across each metric
• The remediation sequence for each failure category: what to investigate first when TTFB is high, when LCP is failing despite fast TTFB, when CLS is elevated
• How to communicate findings to clients: which metrics to surface, what language to use, and how to frame recommended work against business outcomes

The runbook is a living document. Update it when you encounter a new failure pattern, when a major WordPress update changes caching or rendering behavior, or when you add a new site type to your fleet. Over time, a well-maintained runbook is the operational asset that makes your WordPress performance optimization service repeatable across the team and defensible in a client renewal conversation, because the evidence that you are actively managing performance is part of the record.

Uptime monitoring covers whether a site is reachable and responding correctly, not whether it is performing well or producing accurate output. Understanding that boundary is the first step in building a policy that holds up under pressure.

At its core, a monitor pings a URL at a set interval and records the HTTP response code. A 200 means the server responded. A 5xx means it did not respond correctly. A timeout means it did not respond at all. That binary signal, up or down, is the foundation of any WordPress downtime monitoring setup.

A complete monitoring setup for a WordPress agency also covers:

• SSL certificate validity. A site can return 200 but display a browser security warning if the certificate has expired or been misconfigured. Monitor expiry dates, not just current status.
• DNS resolution. A site can be running correctly on the server but unreachable if DNS is broken. External DNS checks catch failures that server-side monitoring misses entirely.
• Keyword confirmation. A monitor can verify that a known string appears in the response, catching cases where the server returns 200 but WordPress is serving a blank screen or error page instead of actual content.

What uptime monitoring does not cover: page speed, broken links, failed form submissions, or content accuracy. Those belong to a separate operating layer. Conflating them leads to either over-alerting (noise that trains your team to ignore alerts) or under-alerting (missing the actual signal that matters). Keep the scope narrow and the signal clear.

Your monitoring policy is the document that determines what counts as downtime for your fleet before any tool is configured. Without that definition, you are making those decisions in real time during an incident, which is the worst possible moment to think clearly.

Three decisions belong in the policy before anything else:

1. What triggers an alert. One failed check is usually noise. A monitor that fires on every transient network blip trains your team to ignore alerts. A standard threshold is two or three consecutive failures within a short window, typically two to five minutes depending on your check interval. Document the number and the interval explicitly.
2. How sites are tiered. A high-revenue transactional site warrants tighter monitoring (one-minute checks, immediate escalation) than a low-traffic brochure site (five or ten-minute checks, business-hours response). Define your tiers, the criteria for placement, and the check frequency that applies to each. Two or three tiers covers most agency fleets without unnecessary complexity.
3. What resolution looks like. An incident is not closed when the site comes back up. It is closed when you have confirmed normal operation, documented the cause, and notified the client where appropriate. Write that definition down before an incident happens.

This policy does not need to be a long document. One or two pages, reviewed whenever you onboard a new client tier or change your monitoring tooling. The goal is that any member of your team can pick it up and run the response without stopping to ask what to do next.

A fleet of client sites needs a single consolidated view, not a separate account for each site. Scattered monitoring creates blind spots, and the site that falls through the cracks is always the one that goes down at 2 AM on a Saturday.

Two practical approaches cover most agencies that manage multiple WordPress sites:

• An external uptime monitoring service with multi-site support. These services run checks from distributed nodes (a check from a single location can miss regional DNS or CDN failures), support alerting rules per monitor, and produce reports you can share directly with clients. Pricing is typically per monitor, so cost scales with your fleet.
• A WordPress uptime monitoring plugin installed on a central control site, which runs outbound checks from within WordPress itself. This works for smaller fleets but carries a structural problem: if the site running the plugin goes down, the monitoring goes with it.

For most agencies operating more than ten client sites, an external service is the more reliable operating layer. A WordPress-side plugin is acceptable as a secondary check or for early-stage setups, but it should not be the primary signal for a production fleet.

When you configure your monitors, apply tags or groups that match your client tiers from the start. That structure pays off when you need to pull a report for a specific client, filter by tier during an incident, or audit coverage after onboarding new sites. Set it up once and the data organizes itself going forward.

Alert routing is where most agency monitoring setups fail: the right person does not get the right context fast enough to act. A monitor that sends every alert to a shared inbox, or to a senior developer who is off on a Friday afternoon, is not a monitoring policy. It is a gap in your operating layer.

Build your response chain in two layers:

Layer 1, initial alert. Who receives the first notification, by what channel (SMS, a phone call, or a dedicated alert channel), and within what time window. For Tier 1 clients, this should be an immediate notification to whoever is on call. For lower-tier clients, email during business hours may be sufficient. Document each tier’s first-alert recipient explicitly, by name rather than just by role.

Layer 2, escalation. If the incident is not acknowledged within a set window (ten or fifteen minutes is common), who does the alert escalate to? This matters most at night and on weekends. An unacknowledged alert that escalates to nobody is a policy gap. Name the person.

Alongside the routing rules, maintain a short response runbook for each incident type. For a server outage: confirm the issue, check the host control panel for active incidents, attempt a restart if your hosting setup permits, and escalate to the host if not resolved within fifteen minutes. For a certificate expiry: identify the issuing authority, initiate renewal, and confirm propagation. A new team member should be able to follow the runbook without prior context.

Every incident, even one resolved in five minutes, should receive a short post-mortem note: cause, timeline, and whether the monitoring caught it first or someone else noticed. Over time, that record identifies which sites are chronically unstable and which hosts are underperforming, data that feeds directly into renewal conversations and infrastructure recommendations.

Informing clients before they find out their site is down separates agencies that operate from agencies that react. Client notification is a formal part of your monitoring policy, not something you improvise under pressure.

Define two notification moments in advance:

At incident start, within fifteen minutes of confirmed downtime for Tier 1 clients: a short, factual message. You are aware their site is down. You are investigating. You will update them within thirty minutes or when it resolves, whichever comes first. Do not speculate on cause. State facts and set the next touchpoint clearly.

At resolution: what happened, how it was resolved, and what changes (if any) will prevent a recurrence. Keep it brief. Clients do not need a technical report. They need to know you caught it, fixed it, and have it under control.

For Tier 2 and Tier 3 clients, a same-business-day summary is usually sufficient. The key point is that they hear from you, not that they discover the outage on their own and follow up asking what happened.

Pre-write both notification templates and store them where whoever handles client communication can reach them quickly. A clear, calm message sent in five minutes is more valuable than a polished one sent in forty-five. The template removes the cognitive load of writing under pressure when something is actively broken.

Monthly uptime reporting converts your monitoring work into a visible, concrete deliverable inside every client care plan. Without it, the value of running a monitoring operation is invisible to clients. With it, uptime data becomes a line item that gives the retainer tangible proof of value.

A useful uptime report for a client care plan contains three elements:

1. Uptime percentage for the period. Most monitoring services calculate this automatically. 99.9% uptime means roughly 44 minutes of downtime per month. 99.5% is around three and a half hours. Presenting a specific number gives clients something concrete to hold.
2. Incident log. Any periods of downtime recorded during the month, with start time, end time, duration, and a one-line cause. Even when there were no incidents, say so explicitly. “Zero incidents this month” is a positive data point worth reporting, not a blank section.
3. SSL and DNS status. Certificate expiry dates and DNS resolution confirmation. These are simple to include and demonstrate that your operating layer covers more than whether the site happens to be loading right now.

Uptime reporting also creates a natural path to care plan upgrades. A client whose site experienced two incidents in a month is a candidate for a higher-tier plan with faster response commitments. The data makes that conversation factual rather than a sales pitch.

Pair uptime reporting with your monthly WordPress maintenance routine to deliver a single, comprehensive care plan document each month. Uptime data tells clients their site was running. Maintenance records tell them it was running correctly. Together, they demonstrate an operating layer that clients cannot replicate on their own.

Every migration your agency runs that starts from scratch adds hidden cost: scoping time, missed checks, inconsistent handoffs, and post-launch tickets that should never have been opened. The fix is not a better project plan. It is a runbook, a documented sequence of phases your team runs identically on every client site, regardless of size or complexity.

Most WordPress migration guides focus on the technical steps for a single site. This one is structured differently, because agencies running a client fleet need a framework that compounds across every move, not just a checklist that works once.

A migration runbook has four phases: pre-migration audit, pre-flight environment prep, cutover, and post-migration verification. Each phase ends with a signed-off checklist. The output is not just a moved site. It is a record of every decision made, every credential touched, and every test passed, which matters when a client calls three weeks later asking why their contact form stopped working.

Structuring migrations this way also changes how you staff them. When the steps are fixed, any trained operator on your team can run the migration, not just the person who built the original site. That is how agencies scale past their founding team without degrading quality.

A pre-migration audit is the single most important phase of any WordPress site migration, because errors caught here cost nothing to fix, while the same errors caught after cutover can cost hours of recovery time and client trust.

Before touching any file or database, capture and document:

• Hosting environment: PHP version, server type (Apache or Nginx), MySQL version, memory limit, max upload size, and any server-level caching layers
• Active plugins and themes: version numbers, license keys, and whether each is actively maintained upstream
• Custom functionality: custom post types, taxonomies, rewrite rules, and any code in functions.php or custom plugins
• Media library: total size, any external storage via offload plugins, and a check for broken attachments
• Third-party Connectors: payment gateways, CRM connections, form handlers, analytics scripts, and ad tags
• DNS records: current A, CNAME, MX, and TXT records documented in full before any changes
• SSL certificate status: expiry date and certificate authority
• Performance baseline: current load time and Core Web Vitals scores to compare against after migration

Running a structured pre-migration audit across your fleet, rather than ad hoc per project, also surfaces patterns you can act on at scale. See how to run a WordPress site audit across your entire client fleet for the fleet-level version of this process.

Cutover failures are rarely caused by the migration itself. They are caused by missing access discovered mid-move, when the cost of stopping is highest.

Confirm every item below at least 48 hours before your scheduled cutover window:

• SSH or SFTP credentials to both source and destination servers, tested and confirmed working
• WordPress admin credentials for both source and destination environments
• Database access on the destination: host, port, database name, username, and password all verified
• DNS registrar login confirmed and TTL lowered to 300 seconds at least 24 hours before cutover
• Email routing on destination: SMTP settings, MX records, and any transactional email service API keys
• A staging environment on the destination host with a temporary domain for full testing before DNS switch
• A complete backup of the source site, taken within 24 hours of cutover, stored independently of both hosts

If the destination is a managed WordPress hosting environment built for agencies, confirm explicitly which responsibilities the host handles at the server level (backups, SSL provisioning, object caching) and which remain yours. Document the boundary. Assumptions here create gaps that only appear after the site is live on the new host.

The cutover phase is where most migration errors are introduced, and where a checklist earns its keep. Run these steps in sequence. Do not skip a step because a prior migration went cleanly.

File and database transfer:

• Export the database from source using a method that handles large tables without timeout (WP-CLI or phpMyAdmin with chunked export)
• Transfer all files, including hidden files such as .htaccess
• Import the database on destination and verify row counts match the source export
• Update wp-config.php with destination database credentials
• Run a search-replace for all URLs using a tool that handles serialized data correctly, not a raw SQL replace

Staging verification before DNS change:

• Test all major page types: home, archive, single post, single page, and any commerce or membership pages
• Submit every form type and confirm delivery end-to-end
• Confirm user login and registration flows function correctly
• Verify all third-party Connectors fire correctly using browser developer tools to check network requests
• Run a crawl for broken internal links
• Confirm SSL is active and enforced on the destination domain
• Confirm redirects from any changed URL structures are in place

Do not proceed to DNS cutover until every staging verification item passes. A failed check on staging takes minutes to fix. The same failure discovered after DNS propagation takes much longer and affects real visitors.

DNS cutover timing determines how much data divergence your client’s site accumulates during the move, and how long visitors see an inconsistent state.

Before flipping DNS, confirm that your TTL reduction from the pre-flight phase has propagated fully. With TTL at 300 seconds, most resolvers will pick up the new A record within five to ten minutes of the change.

Enable WordPress maintenance mode only during the window when the live database on the source host is frozen for final export. For most migrations, this window is under 30 minutes. Maintenance mode beyond that window costs the client real traffic and should be avoided unless the site has an active transaction layer (e-commerce, membership, booking) where data divergence between source and destination would cause genuine loss.

Communicate the cutover window to the client before it starts: an exact start time, an expected duration, and a direct contact for the operator running the move. Do not give an estimate range for maintenance mode. Give a specific time and hold to it. Vague windows create unnecessary support escalations.

After the DNS change, monitor propagation from multiple geographic locations using a DNS propagation checker, and watch traffic on the source server drop off to confirm the switch is complete before decommissioning or repurposing the source environment.

The post-migration audit is not optional, and it is not a quick visual check. It is a structured verification pass that compares the live destination site against the baseline captured in the pre-migration audit.

Run these checks within two hours of DNS propagation completing, while you still have access to the source environment:

• Performance: run a fresh Core Web Vitals measurement and compare against the pre-migration baseline. Regressions almost always trace back to caching not configured or object cache not connected on the new host.
• Search indexing: confirm Google Search Console has the destination domain verified and submit a fresh sitemap. Check that no noindex tags from the staging configuration carried over to production.
• Email delivery: send a test from every contact form and a test transactional email (password reset, order confirmation) and confirm delivery, including a spam folder check.
• SSL and security headers: run the destination domain through an SSL checker and an HTTP headers inspector. Confirm HTTPS redirects are enforced and that HSTS is present if it was present on the source.
• Analytics and tracking: confirm your analytics platform is receiving sessions on the destination domain and that no duplicate tracking is firing.
• Broken links: run a full crawl of the destination and export any 4xx responses for immediate resolution.
• Backup configuration: confirm the destination host’s backup schedule is active and that at least one post-migration backup exists before closing the ticket.

Document the result of each check with a pass or fail and a timestamp. This record is your proof of completion if anything is disputed weeks later.

A checklist used once is a document. A checklist used on every migration is a runbook, and the difference is in how you store it, version it, and assign it.

Store the runbook in a format that can be templated per client. Each migration gets its own instance, pre-populated with client-specific details (source host, destination host, primary domain, DNS registrar), with the steps identical across all instances. Name each instance with a consistent convention, such as client shortcode, date, and migration type, so your team can find prior runs when a client question surfaces months later.

Review the runbook after every migration. If a check caught something real, keep it. If a step was consistently skipped without consequence, remove it. A runbook that grows without pruning becomes noise. The goal is a checklist your team can complete without referring back to documentation for every item.

For agencies operating on managed WordPress hosting for multiple clients, the runbook should also document what the host provides automatically so operators do not duplicate those steps or, worse, assume coverage that is not there. The runbook is the operating memory of your migration practice, not any one team member’s personal knowledge.

When migrations run consistently and every step is auditable, they become a commodity service your agency can price, staff, and hand off without the founding team in the room. That is the compounding return of treating your WordPress migration checklist as a permanent operating layer, not a one-time project artifact.