For most agencies, a quarterly full Core Web Vitals baseline paired with a monthly TTFB spot-check is the right cadence. The monthly check catches server-side regressions early, before they affect front-end scores. The quarterly run gives you comparable data to track trends, update triage tiers, and schedule remediation in a regular sprint cycle. An annual full review, paired with a broader site health audit, is the right time to address lower-priority sites and update your runbook.

Largest Contentful Paint (LCP) is the most actionable single metric for fleet triage. It has a clear threshold (2.5 seconds for passing, 4 seconds for failing), it correlates with both search ranking and user experience, and its root causes are well-defined enough to classify quickly without deep investigation. Measure all four metrics (LCP, CLS, TTFB, total asset load), but sort your triage queue by LCP first and cross-reference with business context to sequence your remediation work.

Not necessarily, and installing a caching or optimization plugin without first diagnosing the root cause often adds complexity without moving the numbers. Sites with high TTFB have a server-side problem that a front-end plugin will not resolve. Use the diagnostic metrics to identify the failure category first: TTFB points to server or caching issues, high LCP with fast TTFB points to image or render-blocking issues, and CLS points to layout instability in the theme or third-party embeds. Match the intervention to the category rather than applying a standard plugin stack to every site.

Lab data, from tools like Lighthouse or PageSpeed Insights, is collected in a controlled environment on demand. It is reproducible and comparable across sites, which makes it useful for fleet baselining and triage. Field data, from Google Search Console’s Core Web Vitals report or the Chrome User Experience Report, reflects real user measurements across actual devices and network conditions. Field data is more representative of what users experience but requires enough real traffic to generate. Use lab data for your fleet baseline and triage process; use field data to validate that improvements in lab scores are translating to real-user experience gains.

Uptime monitoring means running automated checks at regular intervals to confirm that a WordPress site is reachable and returning the correct response. It does not cover page speed or content accuracy. For a WordPress agency, it is the base layer of any site health operating policy: the signal that tells you a site is accessible to real visitors right now.

Check frequency should match your client tier. High-revenue or transactional sites warrant one-minute intervals. Standard retainer sites are typically covered by five-minute checks. Brochure or low-traffic sites can run on ten to fifteen-minute intervals. Document the frequency for each tier in your monitoring policy so it applies consistently across your fleet without requiring a manual decision for each site.

Uptime monitoring answers a binary question: is the site responding? Performance monitoring measures how fast it responds and whether user-facing operations complete within acceptable times. Both matter, but they run on separate layers and generate different alert types. Conflating them creates noise and blurs the distinct response each type of issue requires.

Not necessarily. External monitoring services check your sites from outside the WordPress environment, which is more reliable because the check does not depend on WordPress running correctly. A WordPress-side uptime monitoring plugin works as a secondary check for smaller fleets, but for an agency managing multiple WordPress sites, an external service is the more dependable primary layer.

A complete WordPress migration checklist for agencies should cover four phases: a pre-migration audit (documenting the source environment, plugins, DNS, and performance baseline), pre-flight checks (verifying access credentials, staging environment, and backup), a cutover checklist (file and database transfer, staging verification, DNS switch), and a post-migration audit (performance comparison, email delivery, SSL, analytics, and broken link checks). Each phase should end with a signed-off record so the migration is auditable after the fact.

Agencies reduce migration errors by treating each move as an instance of a repeatable runbook rather than a one-off project. A fixed sequence of documented steps, run identically on every client site, removes the variability that causes errors. It also means any trained operator can run the migration, not just the person who originally built the site. The runbook should be reviewed and refined after every migration to incorporate anything new that was caught.

Enable WordPress maintenance mode only during the final database export window on the source host, when you need to freeze live data to prevent divergence between source and destination. For most migrations this window is under 30 minutes. Avoid extended maintenance mode beyond that window, as it costs real traffic. Communicate the exact start time and expected duration to the client in advance.

A post-migration audit compares the live destination site against the baseline captured before the migration. It checks Core Web Vitals against the pre-migration benchmark, email delivery from all form types and transactional triggers, SSL and HTTPS enforcement, Google Search Console verification and sitemap submission, analytics receiving sessions on the new domain, and a full crawl for broken links or 4xx responses. Each item should be documented with a pass or fail and timestamp before the ticket is closed.

The cover page needs the client’s company name, their site URL, the reporting period, and your agency’s name and logo. Nothing else. No third-party tool names, no platform watermarks. The cover signals to the client that this is a document your agency produced specifically for them.

Two to four pages for most clients: an executive summary, four evidence sections (security, performance, stability, work completed), a short recommendations list, and a supporting data appendix if needed. Longer reports do not signal more value. A client receiving a 12-page document every month stops reading it by month three.

Monthly is the standard for active care plans. It is frequent enough to show consistent attention and infrequent enough that each report covers a meaningful period of work. Quarterly is acceptable for lighter plans, but the renewal and upsell mechanism weakens considerably when clients go 90 days without a touchpoint.

A maintenance report covers operational integrity: security, uptime, updates, and site stability. An analytics report covers traffic and conversion outcomes. The two should not be merged. Clients have separate stakeholders for each, and mixing the documents dilutes both. If you offer both, deliver them separately on potentially different cadences.

For minor and security releases, yes. Update core first, then plugins. Core sets the API surface that plugins depend on, so updating core first eliminates the most common source of compatibility errors. The exception is a major core release where plugin compatibility may lag; in that case, stage the core update starting with a canary site and hold the rest of the fleet until your highest-risk plugins have confirmed compatibility.

If the expected core update is not appearing in the WordPress admin, the most common causes are: a plugin or server configuration that has disabled automatic update notifications, a PHP version that does not meet the new release’s requirements, or a maintenance mode setting that blocks the update check. On a fleet, this is also a signal to audit which sites have update notifications suppressed and confirm those suppressions are intentional rather than the result of a forgotten configuration.

Treat it as a diagnostic signal, not an obstacle to override. First, confirm whether the block is a hard compatibility error or an advisory warning. Check the plugin’s changelog to see if a compatible version is available. If the plugin is unmaintained and essential to the site, escalate to the client before taking action. Never override a core update block on a live site without first testing the update on staging with the plugin active.

The answer is a documented, repeatable sequence rather than per-site ad-hoc decisions. Define a risk tier for each site, apply updates in batched groups rather than all at once, and run a standard pre- and post-update checklist each time. A fleet-level update runbook turns a complex governance problem into a repeatable protocol any team member can execute, and the log it generates is your audit trail when something unexpected surfaces days later.

Security hardening is the process of reducing a WordPress site’s attack surface by removing unnecessary access points, enforcing strict configurations, and replacing default settings that prioritize convenience over security. For agencies managing a fleet of client sites, hardening means defining a minimum-security standard and verifying that every site in the fleet meets that standard on an ongoing basis, not just at launch.

At minimum, run a fleet-wide hardening audit monthly. For clients in regulated industries or with elevated risk profiles, run it weekly. The goal is to detect configuration drift, the gradual reversal of hardening decisions that happens through routine site operations, before a gap becomes an exploitable vulnerability.

Configuration drift is when a site’s security posture degrades after its initial hardening. Common causes include plugins that re-enable settings like XML-RPC, migrations that reset file permissions to system defaults, and temporary admin accounts that never get deprovisioned. Without a scheduled audit against a defined hardening standard, drift accumulates silently and the first visible signal is often an incident rather than a routine check.

Yes, and it is the most operationally sound approach. A documented hardening runbook that specifies which checks to run, what the acceptable state is for each check, and what remediation to take when a check fails gives you a repeatable standard. Applying it fleet-wide means every site is audited the same way, and deviations are surfaced systematically rather than discovered during a client escalation.