{ "security": { "https": { "metric_key": "security.https", "title": "HTTPS", "summary": { "html": "

Description

HTTPS (HTTP over TLS) encrypts traffic between browsers and your server. In WordPress, both the home and site URLs should use https://.

Why it matters: Prevents credential/session theft, protects data integrity, improves SEO ranking signals, and is required for modern browser features (e.g., Service Workers, HTTP/2).

Good to know: Mixed HTTP/HTTPS configurations can break cookies, cause mixed-content warnings, and hurt crawlability. Use a valid certificate and HSTS for best practice.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action (partial HTTPS or mixed content):

  1. Install a valid TLS certificate (Let’s Encrypt or vendor).
  2. Update Settings → General so both WordPress Address (URL) and Site Address (URL) use https://.
  3. Replace hard-coded http:// asset URLs (search & replace or use a plugin like Better Search Replace).
  4. Ensure reverse proxy/CDN forwards protocol headers (X-Forwarded-Proto).
" }, "bad": { "body_html": "

Action (HTTP only):

  1. Provision and install a TLS certificate (Let’s Encrypt via host/panel).
  2. Force HTTPS at the edge (server or CDN) and add a 301 HTTP→HTTPS redirect.
  3. Switch WordPress/Site URLs to https:// in Settings → General.
  4. Enable HSTS once stable (max-age=31536000; includeSubDomains; preload).
" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: move the site to HTTPS

  1. Confirm a certificate exists
    In your hosting panel look for an SSL/TLS or Security section. Enable a free Let’s Encrypt certificate or upload a purchased one for the main domain (and www if used).
  2. Switch WordPress URLs
    In Settings → General, change both WordPress Address (URL) and Site Address (URL) from http:// to https://.
  3. Force HTTPS redirects
    Use your host/CDN UI or server config to redirect all http:// requests to https:// with a 301 redirect (for Apache this is usually in .htaccess, for Nginx in the server block).
  4. Fix mixed content
    Search the DB for hard-coded http:// URLs to your own domain (plugins like “Better Search Replace” help) and replace with https://. Reload key pages and check browser dev tools for mixed-content warnings.
  5. Add HSTS once stable
    When everything works over HTTPS only, add Strict-Transport-Security at the server/CDN level so browsers always use HTTPS.

Note: Exact controls and file locations vary a lot by host. If you’re unsure where to put redirects or headers, open a ticket with your hosting provider and attach this report.

", "warn": null, "bad": null } }, "cache_note_html": "

Cache: If you terminate HTTPS at a CDN or reverse proxy, Scope may be seeing the edge, not the origin. When debugging protocol or mixed-content issues, check both the cached front door (CDN) and the raw origin URL, and clear/purge caches after changing URLs or redirects.

", "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "https" } }, "admin_hygiene": { "metric_key": "security.admin_hygiene", "title": "Admin Hygiene", "summary": { "html": "

Description

A set of quick checks to reduce common attack surfaces (e.g., default usernames, legacy features, indexing).

Why it matters: Attackers scan for easy wins—default admin usernames, exposed XML-RPC, or directory listings make brute-force and reconnaissance easier.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Review and harden:

" }, "bad": { "body_html": "

Action (high risk):

  1. Create a new administrator user with a unique username and strong password; reassign content; delete the admin user.
  2. Enforce 2FA for admin roles immediately.
  3. Install/enable rate-limiting and login protections (e.g., WAF).
" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: harden admin hygiene

  1. Remove the default admin user
    Go to Users → Add New, create a new admin account with a unique username, log out, then log in as the new account. Edit the old admin user and choose “Delete” → “Attribute all content to” your new admin before confirming.
  2. Enforce strong passwords + 2FA
    Install a reputable security plugin that supports 2FA (e.g. via TOTP app) and require it for administrator roles. Encourage passphrases instead of short passwords.
  3. Limit login attempts
    In your security or WAF plugin, enable login rate-limiting or reCAPTCHA to slow down brute-force attempts.
  4. Lock down admin access where possible
    If you have a VPN or static office IPs, consider IP-allowlisting for /wp-admin/ at the firewall/proxy level.

Note: The exact 2FA and rate-limit settings live inside whatever security plugin or WAF you use; this tile simply reminds you to turn them on and verify they’re enforced for all admin users.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "admin_hygiene" } }, "xmlrpc": { "metric_key": "security.xmlrpc", "title": "XML-RPC", "summary": { "html": "

Description

XML-RPC is a legacy remote procedure call endpoint used by some publishing tools and the mobile app (older flows). It exposes methods for authentication and posting.

Why it matters: If you don’t need it, disabling reduces the attack surface and brute-force vectors. If needed, rate-limit and protect it behind security tooling.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: If not required, disable XML-RPC via a security plugin or server rule. If required (e.g., Jetpack legacy), enable rate-limiting and WAF rules for xmlrpc.php.

" }, "bad": { "body_html": "

Action (actively exposed):

  1. Disable XML-RPC at application (security plugin) or server layer (deny access to /xmlrpc.php).
  2. If unavoidable, allowlist IPs, require WAF bot protections, and enable brute-force mitigation.
" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: lock down XML-RPC

  1. Decide if you still need XML-RPC
    Modern WordPress apps and integrations mostly use the REST API. If you don’t rely on legacy tools like old Jetpack flows or offline blog editors, you can usually disable XML-RPC entirely.
  2. Application-level block (recommended first)
    Install or configure a security plugin that offers a “Disable XML-RPC” or “Block xmlrpc.php” toggle. Enable it and re-test this report.
  3. Server-level block (Apache)
    In the site’s .htaccess or vhost:
    <Files xmlrpc.php> Require all denied</Files>
    Save, then clear caches.
  4. Server-level block (Nginx)
    In your server block:
    location = /xmlrpc.php { deny all; }
    Reload Nginx and purge any reverse-proxy caches.
  5. If you must keep it
    Use your WAF (Cloudflare, Sucuri, etc.) to throttle or allowlist /xmlrpc.php by IP and enable bot/credential-stuffing protections.

Note: Blocking at the server level affects all apps using XML-RPC. Make a quick list of known integrations before you disable it so you can test them afterward.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "security", "metric_id": "xmlrpc" } }, "dir_indexing": { "metric_key": "security.dir_indexing", "title": "Directory Indexing", "summary": { "html": "

Description

If a directory lacks an index file and web server listing is enabled, visitors may see the entire file list (e.g., wp-content/uploads).

Why it matters: Exposes file names, backup archives, and clues that assist attackers. Block listing at the server level or via rules (e.g., Options -Indexes in Apache).

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Disable indexing in web server config (Apache: Options -Indexes; Nginx: omit autoindex on) or place a blank index.html in public directories.

" }, "bad": { "body_html": "

Action (publicly exposed):

  1. Disable auto-indexing immediately (Apache/Nginx rule).
  2. Audit exposed directories (uploads, backups) and remove sensitive files.
  3. Add index.html placeholders if server access is limited.
" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: disable directory indexing

  1. Apache: turn off indexing
    In the main Apache config, vhost, or .htaccess, add:
    Options -Indexes
    Then reload Apache. This prevents “Index of /…” listings.
  2. Nginx: remove autoindex on
    In any location blocks serving your site, either delete autoindex on; or explicitly set:
    autoindex off;
    Reload Nginx when finished.
  3. Fallback: add empty index files
    If you can’t change server config, create a blank index.html in exposed directories such as wp-content/uploads so the server serves that instead of a listing.
  4. Re-run the report
    After changes, reload the site and this report to confirm that directory listings are no longer exposed.

Note: On managed or shared hosting, the indexing toggle is often exposed as a simple “directory listing” or “Indexes” checkbox in the control panel instead of raw config.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "security", "metric_id": "dir_indexing" } }, "user_enum": { "metric_key": "security.user_enum", "title": "User Enumeration", "summary": { "html": "

Description

The ability to derive usernames (e.g., via ?author=1 redirects or error messages).

Why it matters: Knowing valid usernames halves the brute-force problem. Block enumeration to force attackers to guess both username and password.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Add rewrite rules to block author archive enumeration, and configure your security plugin to mask usernames in errors and endpoints.

" }, "bad": { "body_html": "

Action (enumeration detected):

  1. Block ?author= patterns (rewrite to 404) or map to display names only.
  2. Hide usernames from REST and login errors.
  3. Rotate weak credentials and enable 2FA for admins.
" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: block user enumeration

  1. Harden ?author= URLs
    If your theme exposes author archives, prefer public “display names” instead of usernames. Using an SEO or security plugin, redirect ?author=ID patterns to a safe URL or 404.
  2. Mask usernames in error messages
    Configure your security plugin to always return generic login errors (e.g., “Invalid credentials”) instead of revealing whether the username exists.
  3. Restrict REST user endpoints
    Use a security plugin or custom code to limit access to /wp-json/wp/v2/users to authenticated users, or to hide email/username fields from anonymous callers.
  4. Audit public profile URLs
    Scan the site for places where the raw login name is exposed (author slugs, directories, feeds) and switch to display names or anonymized IDs where possible.

Note: Blocking enumeration doesn’t remove the need for strong passwords and 2FA; it simply makes attacks more expensive by hiding valid usernames.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Low-Confidence Signal", "meta": { "section": "security", "metric_id": "user_enum" } }, "headers": { "metric_key": "security.headers", "title": "Security Headers", "summary": { "html": "

Description

HTTP response headers that enforce browser-side security policies.

Why: They mitigate XSS, clickjacking, MIME sniffing, and protocol-downgrade risks by pushing guardrails into the browser.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": null }, "bad": { "body_html": null } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": null, "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "headers" } }, "headers.csp": { "metric_key": "security.headers.csp", "title": "Content-Security-Policy (CSP)", "summary": { "html": "

Description

The Content-Security-Policy header controls which sources the browser may load for scripts, styles, images, etc., drastically reducing XSS and injection risk.

Example

Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; script-src 'self' cdn.example.com; style-src 'self' 'unsafe-inline'; object-src 'none'; frame-ancestors 'self'

Notes

CSP Reporting

You can instruct browsers to send JSON reports when violations occur by adding either report-to (modern) or report-uri (legacy) directives.

Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

Combine this with a server or endpoint that records CSP violation reports for debugging (e.g., /csp-report endpoint, Report URI, or self-hosted collector).

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Ship a Report-Only CSP with a minimal allowlist; fix violations; then enforce a tighter CSP (remove broad wildcards, replace inline JS with nonces/hashes).

" }, "bad": { "body_html": "

Action (missing CSP):

  1. Add a CSP at your web server or CDN (default-src 'self' baseline, explicit script-src/style-src).
  2. Eliminate unsafe-inline where possible; iterate using Report-Only first.
" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: add a basic Content-Security-Policy

  1. Start in Report-Only mode
    Add a header like this at the web server or CDN level:
    Content-Security-Policy-Report-Only: default-src 'self'
    Optionally add report-to or report-uri to collect violation reports.
  2. Exercise key pages
    Browse the front-end, admin, cart/checkout, and any web apps while monitoring the browser console and your CSP reports for blocked resources.
  3. Tighten the policy
    Add explicit script-src, style-src, img-src, etc. for the domains you actually use. Where possible, replace inline scripts with nonce or hash-based allowances.
  4. Switch to enforcing CSP
    Once you’re comfortable with the violations, change the header name to Content-Security-Policy (dropping -Report-Only), then retest critical flows.

Important: CSP is powerful and easy to misconfigure. Always test in staging or during a low-risk window, and keep a way to quickly roll back header changes if something critical breaks.

", "warn": null, "bad": null } }, "cache_note_html": "

Cache: CSP headers are often set at the CDN or proxy layer. After changing CSP, purge any page and edge caches or you may keep seeing violations from an old policy. If origin and CDN send different headers, Scope will only reflect the layer it is actually hitting.

", "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "headers.csp" } }, "headers.hsts": { "metric_key": "security.headers.hsts", "title": "Strict-Transport-Security (HSTS)", "summary": { "html": "

Description

HSTS tells browsers to always use HTTPS for your domain, preventing SSL-stripping/downgrade attacks after first visit.

Example

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Notes

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Confirm site-wide HTTPS, then start with a smaller max-age (e.g., 10800) and ramp to 31536000; add includeSubDomains when ready.

" }, "bad": { "body_html": "

Action (no HSTS on HTTPS site):

  1. Add Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.
  2. Once stable, submit for HSTS preload.
" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: enable HSTS safely

  1. Verify 100% HTTPS coverage
    Confirm every hostname you plan to protect (including subdomains if you will use includeSubDomains) serves valid HTTPS and no mixed-content errors.
  2. Add a short HSTS header first
    Start with a conservative max-age, for example:
    Strict-Transport-Security: max-age=10800
    so you can easily back out if needed.
  3. Ramp up max-age
    Once confident, increase to max-age=31536000 (1 year) and add includeSubDomains when all subdomains are HTTPS-only.
  4. Optional: preload
    After running a strict policy for a while, you can add preload and submit the domain to the HSTS preload list.

Warning: Long HSTS + preload is effectively irreversible in the short term. Do not enable it until you are certain you’ll never need to serve HTTP on that domain again.

", "warn": null, "bad": null } }, "cache_note_html": "

Cache: HSTS is cached by browsers for its entire max-age, independent of your HTML/page cache. Once you ship a strict HSTS header and it is cached, users will keep enforcing it even if you roll back at the server. Treat changes carefully and don’t rely on cache clears to undo HSTS quickly.

", "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "headers.hsts" } }, "headers.xfo": { "metric_key": "security.headers.xfo", "title": "X-Frame-Options", "summary": { "html": "

Description

X-Frame-Options controls whether your pages can be framed by other sites, mitigating clickjacking.

Example

X-Frame-Options: SAMEORIGIN

Notes

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Set X-Frame-Options: SAMEORIGIN (or CSP frame-ancestors 'self') except where embedding is explicitly required.

" }, "bad": { "body_html": "

Action (missing): Add X-Frame-Options: SAMEORIGIN globally (or define a CSP frame-ancestors policy).

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: set X-Frame-Options

  1. Decide on framing policy
    If you never need your pages inside iframes, use DENY. If you only frame your own pages, use SAMEORIGIN.
  2. Configure at server or CDN
    Add a response header:
    X-Frame-Options: SAMEORIGIN
    (or DENY) via your web server config or CDN rules.
  3. Check for legitimate embeds
    If you provide widgets others embed on their sites, consider moving framing rules into CSP frame-ancestors instead, where you can specify multiple allowed origins.
  4. Retest UIs using iframes
    Verify any admin previews, page builders, or payment forms that rely on iframes still function as expected.

Note: Browser support has evolved toward CSP frame-ancestors; for new setups, prefer CSP plus a conservative fallback X-Frame-Options header.

", "warn": null, "bad": null } }, "cache_note_html": "

Cache: If different cache layers or backends send different X-Frame-Options, users may see inconsistent framing behavior. Make sure the policy is set in a single place (origin or CDN) and then purge caches so all responses agree.

", "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "headers.xfo" } }, "headers.xcto": { "metric_key": "security.headers.xcto", "title": "X-Content-Type-Options", "summary": { "html": "

X-Content-Type-Options prevents MIME sniffing so browsers don’t treat files as a different type than declared, reducing certain injection risks.

Example

X-Content-Type-Options: nosniff

Notes

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Add X-Content-Type-Options: nosniff at server/CDN level.

" }, "bad": { "body_html": "

Action (missing): Enforce nosniff globally; verify presence on HTML/CSS/JS responses.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: add X-Content-Type-Options

  1. Set the header globally
    At the web server or CDN layer, add:
    X-Content-Type-Options: nosniff
    for HTML, CSS, JS, and other text assets.
  2. Verify correct MIME types
    Use browser dev tools (Network tab) to ensure assets are sent with appropriate Content-Type values (e.g., text/html, text/css, application/javascript).
  3. Retest key flows
    Browse the site normally and check for console warnings or blocked resources related to MIME types.

Note: This header is low-risk; most modern stacks already expect and recommend nosniff.

", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Some CDNs or optimization plugins can strip or rewrite security headers, including X-Content-Type-Options. If Scope shows this header missing but you added it at the origin, check edge/cache rules and purge caches to ensure the header isn’t being dropped.

", "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "headers.xcto" } }, "headers.referrer_policy": { "metric_key": "security.headers.referrer_policy", "title": "Referrer-Policy", "summary": { "html": "

Referrer-Policy controls how much of the referring URL is shared when users navigate away from your pages or load subresources. It protects user privacy and reduces accidental data leakage through query strings.

Example

Referrer-Policy: strict-origin-when-cross-origin

Notes

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Set Referrer-Policy: strict-origin-when-cross-origin (or stricter) on HTML responses.

" }, "bad": { "body_html": "

Action (missing/weak policy): Add a restrictive Referrer-Policy to prevent leaking sensitive URLs; validate that analytics still receive necessary referrer info.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: set a safe Referrer-Policy

  1. Pick a default policy
    For most production sites, Referrer-Policy: strict-origin-when-cross-origin balances privacy and analytics.
  2. Add the header
    Configure the header at the server or CDN level so that HTML responses include the desired Referrer-Policy value.
  3. Test analytics and referral data
    After deployment, confirm that your analytics platform still shows meaningful referrers while sensitive query strings are not leaked cross-origin.

Note: You can go stricter (like no-referrer) if privacy is more important than seeing referrer details in analytics.

", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Referrer-Policy is usually set at the edge. If analytics or referrer behavior doesn’t match what Scope reports, verify which layer (origin vs CDN) is actually sending the header and clear/page-rules caches after changing it.

", "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "headers.referrer_policy" } }, "permissions": { "metric_key": "security.permissions", "title": "Filesystem Permissions", "summary": { "html": "

Description

Effective UNIX permissions on sensitive files and directories (e.g., wp-config.php, wp-content/uploads).

Why it matters: Overly permissive modes let other system users or processes read/alter configuration or upload shells. Follow least privilege.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": null }, "bad": { "body_html": null } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": null, "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "permissions" } }, "permissions.wp_config_mode": { "metric_key": "security.permissions.wp_config_mode", "title": "wp-config.php Permissions", "summary": { "html": "

Description

Permission mask for wp-config.php (e.g., 0640).

Why it matters: Contains DB credentials and keys. Ensure it’s not world-readable. Common safe values: 0640 or 0600 depending on PHP handler.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Tighten to 0640 or 0600 (owner read; group read where required). Ensure ownership matches PHP user.

" }, "bad": { "body_html": "

Action (too permissive): Immediately set chmod 600 wp-config.php (or 640 if group-read is needed) and verify correct ownership.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: tighten wp-config.php permissions

  1. Identify the PHP user
    On managed hosting this is usually documented. On SSH shells you can often infer it from the owner of existing WordPress files.
  2. Adjust file mode safely
    From the web root (where wp-config.php lives), run:
    chmod 640 wp-config.php
    or, on single-tenant hosts:
    chmod 600 wp-config.php
  3. Verify ownership
    Ensure the file is owned by the user and group that PHP runs as so WordPress can still read it.
  4. Re-run the report
    Confirm that permissions are no longer flagged as too permissive.

Warning: Do not change ownership to root or a user that PHP cannot read; that can break the site. When in doubt, ask your host to apply a secure mode for you.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "permissions.wp_config_mode" } }, "permissions.uploads_mode": { "metric_key": "security.permissions.uploads_mode", "title": "Uploads Directory Permissions", "summary": { "html": "

Description

Permission mask for wp-content/uploads.

Why it matters: Too permissive can allow execution of malicious uploads or unintended reads. Typical safe pattern: directories 0755, files 0644, with server rules to block PHP execution.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Normalize to dir 0755, files 0644; block PHP execution in uploads via .htaccess or Nginx location rules.

" }, "bad": { "body_html": "

Action (insecure): Lock down file modes immediately; add php_flag engine off (Apache) or Nginx rules to prevent code execution in uploads.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: normalize uploads permissions

  1. Standardize directory and file modes
    From the WordPress root (or via your hosting file manager), apply:
    find wp-content/uploads -type d -exec chmod 755 {} \\; find wp-content/uploads -type f -exec chmod 644 {} \\;
    This matches common shared-hosting defaults.
  2. Block PHP execution in uploads
    On Apache, add an .htaccess inside wp-content/uploads:
    <FilesMatch \"\\.php$\"> Deny from all</FilesMatch>
    On Nginx, use a location rule that denies executing PHP scripts under /wp-content/uploads.
  3. Retest media flows
    Upload a new image from Media → Add New and ensure it renders normally on the front-end.

Note: Some managed hosts already enforce these rules; if your changes are being auto-reverted, check host documentation for their recommended approach.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "permissions.uploads_mode" } }, "updates": { "metric_key": "security.updates", "title": "Update Posture", "summary": { "html": "

Description

A summary of pending updates for WordPress core, plugins, and themes.

Why it matters: Many compromises exploit known, patched vulnerabilities. Establish a cadence (e.g., weekly) and use staging for smoke tests.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Schedule a maintenance window to apply pending updates in staging, verify key flows, then promote to production.

" }, "bad": { "body_html": "

Action (overdue/critical): Update immediately starting with core and high-risk plugins. Back up first; test; then deploy to production.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: create a safe update routine

  1. Establish a backup habit
    Before any large batch of updates, ensure you have a recent file and database backup (from a backup plugin or host snapshot).
  2. Use staging when available
    If your host provides a staging environment, clone production, apply updates there first, and smoke-test key flows (login, checkout, forms).
  3. Update core, then plugins, then themes
    In Dashboard → Updates, update WordPress core, then critical plugins (security, e-commerce), then the rest, followed by themes.
  4. Schedule a recurring window
    Pick a low-traffic weekly or bi-weekly window to repeat this process so the “pending updates” count stays small.

Note: For high-traffic or revenue-critical sites, treat updates like mini-deployments: changelog review, staging tests, timed rollout, and ability to roll back.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "updates" } }, "updates.core": { "metric_key": "security.updates.core", "title": "Core Updates", "summary": { "html": "

Description

Available updates to WordPress core.

Why it matters: Core releases often include security patches and compatibility improvements. Keep core current, especially on LTS branches.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Update to the latest minor release; review plugin/theme compatibility notes.

" }, "bad": { "body_html": "

Action (outdated core): Backup, update core immediately, and re-run a security scan once live.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: update WordPress core

  1. Back up first
    Ensure you have a current database and file backup (via plugin or hosting snapshot).
  2. Update via Dashboard
    Go to Dashboard → Updates and click Update Now under WordPress core. Wait for the process to complete without closing the browser tab.
  3. Verify the site
    Check front-end, login, and a few admin screens for fatal errors or layout issues. Clear caches if something looks stale.
  4. Fallback plan
    If the update breaks the site and you can’t quickly fix it, restore from the backup you took at step 1 and investigate in staging.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "updates.core" } }, "updates.plugins": { "metric_key": "security.updates.plugins", "title": "Plugin Updates", "summary": { "html": "

Description

Available updates to installed plugins.

Why it matters: Third-party plugins are a leading source of vulnerabilities. Audit riskier plugins and keep them patched.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Update all non-breaking plugins; stage-test feature-critical ones.

" }, "bad": { "body_html": "

Action (security risk): Immediately update plugins with known vulnerabilities; consider temporary deactivation if patches aren’t available.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: update plugins safely

  1. Prioritize security-sensitive plugins
    Update items that handle auth, payments, forms, and admin access first, especially if their changelog mentions security fixes.
  2. Use bulk update with care
    In Plugins → Installed Plugins, select a small batch, choose “Update” from the bulk actions menu, and apply. Avoid updating dozens at once on mission-critical sites.
  3. Test critical flows
    After each batch, test checkout, forms, login, and any custom flows that generate revenue or important data.
  4. Remove unused plugins
    Deactivate and delete plugins you no longer need; they still represent risk even if inactive.

Note: Auto-updates are convenient but can break sites silently. Use them selectively and keep staging in the loop for larger stacks.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "updates.plugins" } }, "updates.themes": { "metric_key": "security.updates.themes", "title": "Theme Updates", "summary": { "html": "

Description

Available updates to installed themes.

Why it matters: Themes can ship PHP and JS with vulnerabilities. Update and remove unused themes.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Update child/parent themes; remove unused themes to reduce surface.

" }, "bad": { "body_html": "

Action (security/compat): Update active theme now; if blocked by customizations, port changes to a child theme and update base.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

Manual fix option: update and clean up themes

  1. Ensure a child theme for customizations
    If you’ve modified theme files directly, create a child theme and move customizations there before updating the parent.
  2. Update active parent/child
    In Appearance → Themes or Dashboard → Updates, apply updates to the active theme pair.
  3. Remove unused themes
    Delete old or unused themes (apart from one default theme you keep for debugging) to reduce surface area.
  4. Check templates
    Visit a few template variations (blog index, single post, page, any custom templates) to confirm layout and functionality remain intact.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "security", "metric_id": "updates.themes" } } }, "plugins": { "summary": { "metric_key": "plugins.summary", "title": "Plugin Inventory", "summary": { "html": "

Description

A breakdown of total, active, inactive, and must-use (MU) plugins.

Why it matters: Each plugin adds code paths and supply-chain risk. Fewer, well-maintained plugins mean lower attack surface and better performance.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Trim unused plugins; consolidate overlapping functionality; keep only supported, frequently updated plugins.

" }, "bad": { "body_html": "

Action (risky footprint): Deactivate/remove unused and unmaintained plugins immediately; replace with supported alternatives.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to audit your plugin inventory

  1. In WordPress, go to Plugins → Installed Plugins.
  2. Make a quick list: must-have, nice-to-have, and unused plugins.
  3. Deactivate one unused plugin at a time and verify the site still behaves as expected.
  4. Once confident, delete unused plugins (files and data) to reduce attack surface.
  5. Document which plugins are business-critical so you can spot surprises when this inventory changes.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "plugins", "metric_id": "summary" } }, "list": { "metric_key": "plugins.list", "title": "Installed Plugins", "summary": { "html": "

Description

The list of installed plugins with version, author, status, and update availability.

Why it matters: Helps you spot outdated or risky plugins. Prefer reputable vendors with frequent updates and clear changelogs.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Prioritize updates for security-sensitive plugins (forms, e-commerce, auth). Review changelogs before deploying.

" }, "bad": { "body_html": "

Action (high-risk set): Remove abandoned plugins; patch critical ones first; enable a staging test cycle for the rest.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to use the installed plugins list

  1. Open Plugins → Installed Plugins in the WordPress admin.
  2. Sort or visually scan for plugins that show available updates (usually highlighted or marked).
  3. For each critical plugin (e.g., forms, e-commerce, auth), read the changelog before updating.
  4. Apply updates in a staging site first when possible; then repeat on production.
  5. Remove any plugins you do not recognize or that your team no longer relies on, after verifying impact.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "plugins", "metric_id": "list" } }, "mu_plugins": { "metric_key": "plugins.mu_plugins", "title": "Must-Use (MU) Plugins", "summary": { "html": "

Description

Plugins auto-loaded from wp-content/mu-plugins.

Why it matters: They always run and can’t be deactivated from the standard UI. Use for site-critical bootstrap code, not routine features.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Review MU plugins; ensure they’re minimal, documented, and version controlled.

" }, "bad": { "body_html": "

Action (misuse): Move non-essential MU plugins to standard plugins; keep MU for critical bootstrap only.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to review MU plugins

  1. In the admin, go to Plugins → Must-Use (if your host exposes that tab).
  2. Using SSH/SFTP, inspect the wp-content/mu-plugins/ directory to see exactly which files are loaded.
  3. Confirm each MU plugin is tracked in version control or deployment scripts; avoid ad-hoc edits in production.
  4. Move non-critical functionality out of MU into regular plugins so they can be deactivated/updated more safely.
  5. Document which MU plugins are required for the site to boot correctly (caching drop-ins, security bootstraps, etc.).
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "plugins", "metric_id": "mu_plugins" } }, "abandoned": { "metric_key": "plugins.abandoned", "title": "Potentially Abandoned", "summary": { "html": "

Description

Heuristic indicating plugins that haven’t seen updates in a long time (e.g., > 12 months).

Why it matters: Unmaintained code accumulates vulnerabilities. Vet or replace with maintained alternatives.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Evaluate vendor activity and community reports; plan replacement if maintenance is uncertain.

" }, "bad": { "body_html": "

Action (unmaintained): Replace immediately with a supported plugin; validate data migration paths.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to handle potentially abandoned plugins

  1. From Plugins → Installed Plugins, click each flagged plugin’s View details link.
  2. Check the Last updated date and Tested up to version in the plugin details or WordPress.org page.
  3. Search the plugin slug plus “vulnerability” or check a security database if this plugin is widely used.
  4. If the vendor appears inactive, research alternatives that provide similar functionality and are actively maintained.
  5. Plan and test a replacement: migrate settings/data in a staging site, then switch in production during a maintenance window.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "plugins", "metric_id": "abandoned" } }, "duplicates.cache_plugins": { "metric_key": "plugins.duplicates.cache_plugins", "title": "Multiple Caching Plugins", "summary": { "html": "

Description

Detection of more than one caching/optimization plugin.

Why it matters: Overlapping features cause conflicts, stale caches, and performance regressions. Consolidate to a single cache layer.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Choose one primary page/object cache; disable others; clear all caches.

" }, "bad": { "body_html": "

Action (conflicts likely): Immediately deactivate redundant cache plugins; keep a single, well-supported solution.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to resolve multiple caching plugins

  1. List all active caching/optimization plugins (page cache, object cache, full-page CDN integrations).
  2. Decide which layer is primary (for example, host-level cache or a single WordPress caching plugin).
  3. Deactivate extra caching plugins one at a time and clear all caches after each change.
  4. Verify page behavior, logins, and admin performance before moving to the next deactivation.
  5. Once stable, keep one primary cache and configure purge/invalidation rules around deploys and content edits.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Multiple page/object/cache plugins plus a CDN can hide which layer is serving a response. When chasing odd behavior in other tiles (headers, HTTPS, SEO), temporarily disable extra cache plugins, clear all caches, and test through a single, known cache layer.

", "links": [], "titleBadge": null, "meta": { "section": "plugins", "metric_id": "duplicates.cache_plugins" } }, "licenses_missing": { "metric_key": "plugins.licenses_missing", "title": "License/Key Gaps", "summary": { "html": "

Description

Plugins that require licenses/keys but none detected.

Why it matters: Missing licenses can block updates and security patches. Ensure production has valid keys.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Add/update license keys on production to restore updates.

" }, "bad": { "body_html": "

Action (blocked updates): Enter valid licenses now to receive security patches; remove the plugin if a license cannot be procured.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to fix license/key gaps

  1. From Plugins, open each plugin that requires a license or API key; look for a dedicated settings page or a License tab.
  2. Log into the vendor account or marketplace (e.g., WooCommerce.com, Envato, vendor portal) and locate your license keys.
  3. Enter the key into the plugin’s settings on the production site, not just on staging.
  4. Trigger a manual update check (Dashboard → Updates) to confirm that updates are now available.
  5. Keep a secure internal record of license locations and renewal dates so this doesn’t silently regress.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "plugins", "metric_id": "licenses_missing" } } }, "server": { "database": { "metric_key": "server.database", "title": "Database", "summary": { "html": "

Description

Database vendor and version (MySQL or MariaDB).

Why it matters: Newer engines offer performance, stability, and features (e.g., improved InnoDB). Some WP plugins require minimum versions.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Plan an upgrade to a currently supported LTS release; verify backups and staging compatibility (charset/collation) before migration.

" }, "bad": { "body_html": "

Action (outdated/unsupported): Migrate to a supported version ASAP; take full backups, test restores, and schedule a maintenance window.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to check and upgrade the database server

  1. In your hosting control panel or via mysql --version, confirm the current MySQL/MariaDB version.
  2. Compare it against the host’s documented supported versions and WordPress recommendations.
  3. If you are below a supported LTS version, open a ticket or schedule an upgrade in your hosting dashboard.
  4. Before upgrading, take a full database backup (via phpMyAdmin, WP-CLI wp db export, or your backup tool).
  5. After the upgrade, re-run key site flows and re-check the Scope report for any new warnings.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "database" } }, "opcache": { "metric_key": "server.opcache", "title": "OPcache", "summary": { "html": "

Description

PHP bytecode cache (and optional JIT) that keeps compiled scripts in memory.

Why it matters: Dramatically reduces CPU and improves response times under load.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Enable OPcache with sensible defaults; ensure adequate memory (opcache.memory_consumption) and set revalidate_freq for your deploy process.

" }, "bad": { "body_html": "

Action (disabled/misconfigured): Turn on OPcache; size memory (e.g., 128–256MB for typical sites), and confirm it survives restarts.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to enable and tune OPcache

  1. Locate your PHP configuration (php.ini, .user.ini, or hosting UI).
  2. Ensure opcache.enable=1 and opcache.enable_cli=1 (if you use CLI tools) are set.
  3. Set opcache.memory_consumption to a reasonable size (e.g., 128–256M for typical WordPress sites).
  4. Configure opcache.max_accelerated_files high enough for your codebase (e.g., 10000+).
  5. Restart PHP / your web server, then confirm OPcache is active via phpinfo() or your host’s tools.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: OPcache is separate from page/CDN caches. If you change PHP code or configuration and don’t see it reflected, you may need to flush OPcache and clear any full-page caches so Scope (and users) see the updated behavior.

", "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "opcache" } }, "object_cache": { "metric_key": "server.object_cache", "title": "Object Cache", "summary": { "html": "

Description

Persistent cache layer (Redis/Memcached) for WordPress objects and queries.

Why it matters: Reduces database load and speeds up dynamic pages and admin.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Enable a persistent object cache (Redis or Memcached) and verify connection health and eviction policy.

" }, "bad": { "body_html": "

Action (none/unstable): Install and configure Redis/Memcached; monitor hit ratio and memory pressure; fix timeouts.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to configure a persistent object cache

  1. Decide on a backend (Redis or Memcached), usually based on host support.
  2. Enable the service in your hosting panel or provision it yourself (managed Redis, container, or VM).
  3. Install a reputable object cache plugin (e.g., Redis Object Cache, Memcached-based plugin) and follow its connection instructions.
  4. Verify connection status and watch for errors in debug logs.
  5. Measure admin and frontend performance before and after enabling object cache to confirm benefit.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: A persistent object cache can keep options and transients around after you change settings. If a tile still reports old values, clear the object cache (Redis/Memcached) and re-run the report, especially after big config or plugin changes.

", "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "object_cache" } }, "php_version": { "metric_key": "server.php_version", "title": "PHP Version", "summary": { "html": "

Description

The PHP runtime version executing WordPress.

Why it matters: Supported versions get security fixes and run faster. Upgrading often yields major performance gains.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Plan upgrade to a currently supported PHP (e.g., 8.1+). Test in staging for deprecated features before rollout.

" }, "bad": { "body_html": "

Action (EOL PHP): Upgrade PHP immediately via hosting panel or ops; fix deprecated API usage in staging, then go live.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to safely upgrade PHP

  1. Check the current PHP version via Scope, phpinfo(), or your hosting panel.
  2. In a staging environment, switch to the target PHP version (for example, 8.1+), then run through key flows (checkout, forms, logins, editor).
  3. Fix any deprecation notices or fatals by updating plugins/themes or contacting vendors.
  4. Once staging is clean, change PHP version for the production site from the hosting panel.
  5. Monitor error logs and the Scope report for 24–48 hours for any new issues.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "php_version" } }, "mysql_version": { "metric_key": "server.mysql_version", "title": "MySQL/MariaDB Version", "summary": { "html": "

Description

The database server version (MySQL or MariaDB).

Why it matters: Newer engines bring better performance and features (e.g., improved InnoDB). Ensure compatibility with your host.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Schedule DB engine upgrade to a supported LTS; verify charset/collation and backups beforehand.

" }, "bad": { "body_html": "

Action (outdated DB): Migrate to a supported version; run backups and test restore, then perform in a maintenance window.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to plan a DB engine upgrade

  1. Confirm the exact database engine and version (MySQL vs MariaDB) via your host or SELECT VERSION();.
  2. Check your host’s documentation for recommended upgrade paths and whether in-place or migration upgrades are used.
  3. Take full backups (database export and, ideally, a snapshot) before any change.
  4. Schedule the upgrade during a low-traffic window, and coordinate with your host if they handle the change.
  5. Afterward, verify connection credentials, charset/collation, and run through critical site workflows.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "mysql_version" } }, "server_software": { "metric_key": "server.server_software", "title": "Web Server", "summary": { "html": "

Description

The HTTP server stack (Apache, Nginx, LiteSpeed, etc.).

Why it matters: Determines available modules, rewrite rules, and tuning knobs. Align caching/compression with the stack.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Ensure TLS/HTTP/2 or 3 is enabled; align rewrite and caching modules with your chosen stack; remove unused modules.

" }, "bad": { "body_html": "

Action (misconfig/legacy): Update server packages; standardize a modern stack (e.g., Nginx/LiteSpeed with HTTP/2/3) and reapply hardened configs.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to align with your web server stack

  1. Identify the stack via Scope (Apache, Nginx, LiteSpeed, etc.) or your hosting panel.
  2. Review how redirects, compression, and caching are configured at the server or CDN level.
  3. Ensure there is a single, clear source of truth for redirects (either application or server, not both competing).
  4. Confirm HTTP/2 or HTTP/3 is enabled if supported by your host.
  5. Document where configuration actually lives (vhosts, .htaccess, Nginx includes, or host UI) so changes are reproducible.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Stack detection can be skewed by a CDN masking the true origin (for example, seeing “cloudflare” instead of Apache/Nginx). If results look off, hit the origin host directly or bypass the CDN, then re-run the report to get an accurate view of the underlying server and cache stack.

", "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "server_software" } }, "memory_limit": { "metric_key": "server.memory_limit", "title": "PHP Memory Limit", "summary": { "html": "

Description

Max memory the PHP process can consume.

Why it matters: Too low can cause fatals under load; too high masks memory leaks. Typical WordPress sites run comfortably at 256–512MB.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Raise to at least 256M in php.ini/.user.ini or host UI; profile heavy plugins.

" }, "bad": { "body_html": "

Action (too low/fatals likely): Increase to 256M–512M immediately; audit error logs for OOM and optimize offending plugins.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to adjust PHP memory limit

  1. Check the current memory_limit via Scope or phpinfo().
  2. If your host allows it, raise memory_limit in php.ini, .user.ini, or the hosting UI (e.g., 256M–512M).
  3. On managed hosts, you may need to open a ticket to request a higher limit.
  4. After changing, reload PHP and confirm the new limit via Scope or a phpinfo page.
  5. If you still see out-of-memory errors, profile heavy plugins or processes instead of raising the limit indefinitely.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "memory_limit" } }, "upload_max": { "metric_key": "server.upload_max", "title": "Upload Max Filesize", "summary": { "html": "

Description

Max allowed size for a single uploaded file (upload_max_filesize).

Why it matters: Impacts media/library workflows. Keep aligned with CDN and post limits.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Align upload_max_filesize with editorial needs (e.g., 64–128MB for media-heavy sites) and ensure post_max_size ≥ this value.

" }, "bad": { "body_html": "

Action (too low): Raise both upload_max_filesize and post_max_size to meet workflow; verify server/client timeouts.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to increase upload_max_filesize

  1. Locate the php configuration controls (php.ini, .user.ini, or hosting UI).
  2. Set upload_max_filesize to a value that fits your editorial workload (for example, 64M or 128M).
  3. Ensure post_max_size is at least as large as upload_max_filesize.
  4. Restart PHP / web server if required.
  5. Test by uploading a file slightly under the new limit in Media → Add New.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "upload_max" } }, "post_max": { "metric_key": "server.post_max", "title": "Post Max Size", "summary": { "html": "

Description

Max size of POST request payload (post_max_size).

Why it matters: Must be ≥ upload limit to allow larger uploads/forms. Coordinate with server-level limits.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Set post_max_size ≥ upload_max_filesize (e.g., 128MB) and ensure reverse proxy/client limits match.

" }, "bad": { "body_html": "

Action (blocking uploads): Increase post_max_size and web server/proxy client_max_body_size (Nginx)/LimitRequestBody (Apache).

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to adjust post_max_size

  1. Open your php settings (php.ini, .user.ini, or host UI).
  2. Set post_max_size to be equal to or larger than upload_max_filesize.
  3. Check your reverse proxy or web server for body size limits (client_max_body_size on Nginx, LimitRequestBody on Apache).
  4. Restart services if needed and test large uploads or form submissions.
  5. If issues persist, check error logs for the exact component rejecting the request.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "post_max" } }, "max_execution_time": { "metric_key": "server.max_execution_time", "title": "Max Execution Time", "summary": { "html": "

Description

Max seconds a PHP script may run.

Why it matters: Long imports/updates may need higher thresholds; excessively high values risk resource lockups.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: For import-heavy workflows, raise to ~120s and optimize slow queries; otherwise keep conservative (30–60s).

" }, "bad": { "body_html": "

Action (too low/timeout errors): Temporarily raise to 120–300s for batch tasks; fix root-cause slowness and revert to a safer default.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to change max_execution_time

  1. Locate the PHP configuration and search for max_execution_time.
  2. Increase it to a reasonable value for your workload (e.g., 60–120 seconds for import-heavy admin tasks).
  3. For long-running CLI processes, prefer running via WP-CLI or background workers rather than huge single web requests.
  4. Restart PHP / web server and confirm the new value via Scope or phpinfo().
  5. Monitor logs to ensure long-running tasks complete without timeouts and without locking up resources.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "max_execution_time" } }, "max_input_vars": { "metric_key": "server.max_input_vars", "title": "Max Input Vars", "summary": { "html": "

Description

Max number of input variables PHP will accept in a single request.

Why it matters: Large menus or settings forms can exceed defaults; raise carefully if needed.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Increase to 3000–5000 if menu/settings save fails; prefer structural simplification over large single forms.

" }, "bad": { "body_html": "

Action (saves failing): Raise max_input_vars (e.g., 5000+), split forms, and remove unused menu items.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to raise max_input_vars

  1. If menu saves or very large forms are failing, open your php configuration and find max_input_vars.
  2. Raise it incrementally (e.g., 3000–5000) rather than jumping to extremely high values.
  3. Apply the change and reload PHP.
  4. Retry the failing operation (saving menus/settings).
  5. If you still have issues, consider restructuring forms or splitting settings across multiple pages.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "max_input_vars" } }, "disk_free": { "metric_key": "server.disk_free", "title": "Disk Space (Free)", "summary": { "html": "

Description

Approximate free disk on the filesystem that hosts your WordPress path (via PHP disk_free_space()).

Why it matters: Low space breaks uploads, updates, and backups.

Note on shared/virtual hosting: This value reflects the filesystem’s free space, not your account quota. On shared or containerized hosts, your panel (cPanel/Plesk) quota can be much smaller.

How to verify: Check your hosting panel’s disk/quota metrics and inode usage. If the panel shows lower free space, trust the panel.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Free space by clearing caches/backups and pruning logs. Verify your account quota in the hosting panel; if nearing quota, purchase more storage or offload media to object storage.

" }, "bad": { "body_html": "

Action (critical): Immediately free space (rotate logs, purge caches, offload media), then expand storage or reduce quota usage. Verify inode usage if errors persist.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to free disk space safely

  1. Check both filesystem free space and your hosting account’s quota/inode usage in the hosting control panel.
  2. Delete old backups, large logs, and cache directories (plugin caches, staging artifacts) after confirming they are safe to remove.
  3. Offload large media (video, archives) to a CDN or object storage when possible.
  4. Review backup configuration to avoid storing many generations on the same disk.
  5. If you are consistently nearing capacity, coordinate with your host to increase the volume size or plan a migration.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "disk_free" } }, "disk_total": { "metric_key": "server.disk_total", "title": "Disk Space (Total)", "summary": { "html": "

Description

Total capacity of the volume hosting uploads/content.

Why it matters: Helps capacity planning for media-heavy sites.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Plan capacity upgrades and/or offload media to a CDN/object storage.

" }, "bad": { "body_html": "

Action (undersized): Increase volume size or offload media immediately to maintain operations.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to plan for disk capacity

  1. Use your host’s analytics or monitoring to understand how quickly disk usage is growing.
  2. Identify large tables, media libraries, and backup files that drive most of the usage.
  3. Move non-essential assets (archives, old exports, temp files) off the main web volume.
  4. Increase storage capacity through your hosting plan if growth is steady and legitimate.
  5. Implement regular cleanup routines so you are not relying solely on manual intervention.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "disk_total" } }, "autoload_size_kb": { "metric_key": "server.autoload_size_kb", "title": "Autoloaded Options Size", "summary": { "html": "

Description

Total size of options loaded on every request (autoload = yes).

Why it matters: Large autoload bloat slows every page. Audit and de-autoload non-critical entries.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Identify large autoloaded options; de-autoload non-critical plugin settings; consider persistent object cache.

" }, "bad": { "body_html": "

Action (bloat): Remove orphaned/unused autoload rows, refactor offending plugins, and enable object caching.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to reduce autoload bloat

  1. Use a DB tool (phpMyAdmin, Adminer, or WP-CLI) to inspect wp_options rows where autoload='yes' and size is large.
  2. Identify options created by plugins that do not need to load on every request (logs, caches, large settings blobs).
  3. For each candidate, either adjust plugin settings or manually set autoload='no' after confirming it is safe.
  4. Remove orphaned options from deactivated plugins.
  5. Re-run the Scope report to confirm autoload size has decreased.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "server", "metric_id": "autoload_size_kb" } }, "error_log_tail": { "metric_key": "server.error_log_tail", "title": "Error Log (Recent)", "summary": { "html": "

Description

Count of recent PHP errors in the server's error log.

Why it matters: A rising error rate signals bugs, deprecations, or resource issues. Fix at source; don’t suppress.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Triage recurring warnings/notices; fix deprecations; keep WP_DEBUG_LOG enabled (display off) in production.

" }, "bad": { "body_html": "

Action (frequent errors): Investigate stack traces, roll back the last change if needed, and hotfix critical errors before proceeding.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to triage recent PHP errors

  1. Locate your PHP or web server error log (often available in the hosting panel or via SSH).
  2. Filter for the most recent entries matching the time window Scope reports.
  3. Group errors by root cause (plugin, theme, custom code) and frequency.
  4. Fix issues starting with fatals and high-frequency warnings, ideally in staging first.
  5. After deploying fixes, clear the log (or note a marker) and confirm that error rates drop over the next day or two.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "error_log_tail" } }, "cron": { "metric_key": "server.cron", "title": "WP-Cron Health", "summary": { "html": "

Description

WordPress's pseudo-cron job status: overdue counts and time to next event.

Why it matters: Overdue tasks indicate traffic/loopback problems. Consider real cron + DISABLE_WP_CRON for busy sites.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Ensure wp-cron.php can run (no auth blocks); reduce overdue jobs; consider real cron for reliability.

" }, "bad": { "body_html": "

Action (stalled): Switch to system cron that hits wp-cron.php, fix loopback failures, and clear stuck jobs.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to stabilize WP-Cron

  1. From the dashboard, install a cron inspector plugin or use WP-CLI (wp cron event list) to see overdue tasks.
  2. If DISABLE_WP_CRON is true, ensure a real system cron is calling wp-cron.php on a schedule (e.g., every 5–10 mins).
  3. Fix loopback issues (auth blocks, firewalls) that prevent WordPress from calling itself.
  4. Clear obviously stuck jobs and re-schedule them if needed.
  5. Monitor scheduled tasks for a few days to ensure new events run on time.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "cron" } }, "timezone": { "metric_key": "server.timezone", "title": "Time zone alignment", "summary": { "html": "

WordPress uses its own configured time zone for scheduling posts, cron jobs, and how dates are shown in the admin. The underlying PHP/server time zone can be different.

When these disagree, you may see confusing timestamps (\"off by a few hours\"), missed or late cron events, and reports that don't line up with reality.

Ideally, WordPress should be set to a named city time zone (for example, America/Chicago) under Settings → General, and your server's PHP date.timezone should match. If this card is flagged, ask your host or devops to align the PHP time zone with WordPress, or adjust the WordPress setting if the server time zone is your source of truth.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": null }, "bad": { "body_html": null } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": null, "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "timezone" } }, "image_toolkit": { "metric_key": "server.image_toolkit", "title": "Image Toolkit", "summary": { "html": "

Description

WordPress uses server-side libraries (Imagick and/or GD) to resize and process images. If neither is available, thumbnail generation and media edits can fail. WebP/AVIF support reduces file size and improves page performance.

Note: AVIF/HEIC support depends on how ImageMagick/GD was compiled on your host.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": null }, "bad": { "body_html": null } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to improve image processing support

  1. Ask your host which image libraries are installed (Imagick, GD) and which formats they support (WebP, AVIF).
  2. If Imagick is missing and your workload is image-heavy, request it be enabled or upgrade to a plan that includes it.
  3. Enable WebP (and AVIF if available) in your image optimization or CDN tool.
  4. Test uploading and regenerating thumbnails to ensure there are no processing errors.
  5. Consider moving large image optimization tasks to a background worker or external service if performance is an issue.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "server", "metric_id": "image_toolkit" } } }, "performance": { "cache_detected": { "metric_key": "performance.cache_detected", "title": "Page Cache", "summary": { "html": "

Description

Whether a known caching layer/plugin is active.

Why it matters: Static caching drastically reduces TTFB and CPU usage. Use exactly one page caching layer to avoid conflicts.

Tip: If your CDN does full-page caching, configure the plugin to handle purges rather than double-caching.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Enable a single, reputable page cache (e.g., server cache, LiteSpeed, or a plugin) and purge on deploys.

" }, "bad": { "body_html": "

Action (no caching): Install and configure page caching immediately; verify headers and cache hit ratios.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to enable effective page caching

  1. Decide whether caching is handled at the host/CDN level or via a WordPress plugin.
  2. If you choose a plugin, install one reputable page cache and follow its setup wizard.
  3. Configure cache purge rules for content edits, deploys, and plugin/theme updates.
  4. Use browser dev tools or response headers to confirm cache hits (look for cache-related headers from your CDN or plugin).
  5. Avoid stacking multiple page caches; rely on one main layer and a separate object cache if needed.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: This check only tells you that some cache layer is likely present, not whether it is correctly purging. If you see stale or contradictory results in other tiles, treat this as a hint to review page cache, CDN rules, and invalidation hooks.

", "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "performance", "metric_id": "cache_detected" } }, "compression": { "metric_key": "performance.compression", "title": "HTTP Compression", "summary": { "html": "

Description

Gzip/Brotli compression of responses.

Why it matters: Shrinks payloads and speeds transfer. Brotli generally compresses better (for HTTPS). Ensure it’s enabled for text assets.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Enable gzip/Brotli for HTML/CSS/JS; confirm via response headers (content-encoding).

" }, "bad": { "body_html": "

Action (disabled): Turn on compression in web server/CDN; verify effective compression for all text assets.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to enable HTTP compression

  1. Check if content-encoding: gzip or br appears in your response headers via browser dev tools.
  2. If not, enable Gzip/Brotli in your hosting control panel or in your web server config (Apache, Nginx, or LiteSpeed directives).
  3. Ensure compression is applied at least to HTML, CSS, JS, JSON, and XML responses.
  4. Validate again with dev tools or an external performance test to confirm compression is active.
  5. Watch CPU usage; in most modern setups compression is cheap, but very limited hardware can be impacted.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Compression can be handled by either the origin or CDN. If Scope shows compression disabled but GTmetrix/WebPageTest disagree, you may be looking at different cache layers. Confirm where gzip/Brotli is actually enabled and purge caches after toggling it.

", "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "compression" } }, "db_hygiene": { "metric_key": "performance.db_hygiene", "title": "Database Hygiene", "summary": { "html": "

Description

Signals around transients, revisions, and autoload size.

Why it matters: Excess transients and revisions bloat tables and slow queries. Clean up regularly; use persistent object caching where appropriate.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Prune expired transients, cap revisions, and move non-critical options off autoload.

" }, "bad": { "body_html": "

Action (heavy bloat): Purge transients with SQL, enable object cache (Redis/Memcached), and refactor plugins creating excessive options.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to improve database hygiene

  1. Use a DB tool or WP-CLI to inspect tables for transients, revisions, and very large options rows.
  2. Clear expired transients with a safe cleanup tool or wp transient delete-expired.
  3. Limit post revisions via WP_POST_REVISIONS and prune old revisions.
  4. Address autoload bloat by de-autoloading non-critical options and cleaning up orphaned rows.
  5. Re-run Scope and observe whether DB- and autoload-related metrics have improved.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "db_hygiene" } }, "db_size": { "metric_key": "performance.db_size", "title": "Database Size", "summary": { "html": "

Description

Total size of your database (data + indexes).

Why it matters: Larger DBs need indexing, query tuning, and proper backups. Monitor growth by table.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Add indexes to slow tables, archive old data, and ensure nightly backups.

" }, "bad": { "body_html": "

Action (very large/slow): Optimize and partition heavy tables; add read replicas if needed; ensure reliable offsite backups.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to manage database size

  1. From phpMyAdmin or WP-CLI, inspect table sizes (data + index).
  2. Identify unusually large tables (logs, sessions, analytics, custom plugin tables).
  3. Archive or purge old data where safe (for example, ancient logs, expired sessions, transient-like tables).
  4. Run OPTIMIZE TABLE or host-provided optimization tools on bloated tables.
  5. Implement a recurring cleanup schedule so growth stays predictable.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "db_size" } }, "transient_count": { "metric_key": "performance.transient_count", "title": "Transients", "summary": { "html": "

Description

Count of cached key/value pairs stored in wp_options.

Why it matters: Excess transients indicate plugin misuse or failing external APIs. Prune expired and consider a proper object cache.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Clear expired transients; fix plugins that rewrite transients too frequently; add object cache.

" }, "bad": { "body_html": "

Action (excessive): Bulk-delete orphaned transients; audit offending plugins and migrate to persistent object cache.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to reduce transient bloat

  1. Inspect the count and largest transient-related tables via phpMyAdmin or WP-CLI.
  2. Use a plugin or wp transient delete --all (with care) to clear expired and orphaned transients.
  3. Identify plugins that generate large numbers of transients (API connectors, page builders, heavy dashboards).
  4. Adjust plugin settings to reduce overly aggressive caching in wp_options.
  5. Consider moving to persistent object caching so transients live outside of wp_options.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "performance", "metric_id": "transient_count" } }, "transient_bloat": { "metric_key": "performance.transient_bloat", "title": "Transient Bloat Level", "summary": { "html": "

Description

A simple indicator (low/medium/high) derived from transient counts.

Why it matters: High bloat hurts admin performance and option autoload times.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Reduce plugins creating transients; prune regularly with a scheduled task.

" }, "bad": { "body_html": "

Action (high): Immediate cleanup of transients via SQL/CLI; re-architect caching behavior in plugins.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to handle high transient bloat

  1. If this metric is flagged as high, treat it as a prompt to review both transient counts and autoload size.
  2. Use a DB viewer or dedicated cleanup plugin to list and prune transients responsible for most of the weight.
  3. Work with developers or vendors of the top offenders to reduce write frequency or move to a better caching strategy.
  4. Implement background jobs to periodically clear expired transients.
  5. Re-check performance metrics after cleanup to confirm improvement.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "transient_bloat" } }, "revision_count": { "metric_key": "performance.revision_count", "title": "Post Revisions", "summary": { "html": "

Description

Total count of stored revisions.

Why it matters: Excess revisions consume space. Set sane limits via WP_POST_REVISIONS and prune old revisions.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Set WP_POST_REVISIONS to a reasonable cap (e.g., 10) and prune older revisions.

" }, "bad": { "body_html": "

Action (bloat): Run a revision cleanup tool; cap going forward; verify DB size reductions.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to tame post revisions

  1. Estimate how many revisions you truly need per post/page (e.g., 10–20 for editorial workflows).
  2. Add or adjust WP_POST_REVISIONS in wp-config.php to a sane limit.
  3. Use a reputable cleanup plugin or custom SQL to prune older revisions beyond that limit.
  4. Test editing and rollback workflows to ensure you still have enough history.
  5. Repeat cleanup periodically or make it part of routine maintenance.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "revision_count" } }, "heartbeat.throttled": { "metric_key": "performance.heartbeat.throttled", "title": "Heartbeat Throttling", "summary": { "html": "

Description

Whether the WP Heartbeat API is disabled or throttled.

Why it matters: Heartbeat keeps admin features in sync but can generate high PHP load on busy dashboards. Throttle instead of disabling if you rely on autosave.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Throttle Heartbeat (e.g., 60s+) on admin screens; keep enabled for autosave if editors rely on it.

" }, "bad": { "body_html": "

Action (disabled with issues): Re-enable but throttled; ensure autosave and locks work; monitor server load.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to tune Heartbeat

  1. Confirm whether a Heartbeat control plugin or custom code is already altering intervals.
  2. If Heartbeat is causing load issues, throttle it (for example, to 60+ seconds) instead of fully disabling it.
  3. Keep a reasonable interval on post edit screens to preserve autosave and locking behavior.
  4. Test multi-author editing and locking after changes to ensure you haven’t broken collaboration flows.
  5. Monitor server load during busy editorial windows to verify that tuning helped.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "heartbeat.throttled" } }, "loopback_ttfb": { "metric_key": "performance.loopback_ttfb", "title": "Loopback TTFB", "summary": { "html": "

Description

Time-to-first-byte for a local HTTP request to the site (server-to-itself).

Why it matters: A quick proxy for backend responsiveness—slow values hint at PHP/DB work, external calls, or blocking.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Profile the slow path (plugins, queries, remote APIs); enable OPcache and a persistent object cache; verify no network DNS/proxy delays.

" }, "bad": { "body_html": "

Action (consistently high): Capture callgrind/XHProf traces, optimize heavy queries, and reduce remote blocking calls; consider scaling resources.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to debug slow loopback TTFB

  1. Use WP-CLI or a curl request from the server to hit the site homepage and measure response time.
  2. If responses are consistently slow, enable a profiler (XHProf, Blackfire, or similar) in staging to see which plugins or queries dominate.
  3. Check for slow external API calls that may be blocking page generation.
  4. Enable OPcache and a persistent object cache if not already in place.
  5. Iterate on the heaviest offenders and re-measure loopback response times.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Loopback checks usually bypass the public page cache, so TTFB here can be slower than what real visitors see behind a CDN or page cache. Use it to spot backend bottlenecks, not to judge fully cached front-end performance.

", "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "loopback_ttfb" } }, "cache_plugins": { "metric_key": "performance.cache_plugins", "title": "Caching Plugins", "summary": { "html": "

Description

Detected caching plugins and whether they are active.

Why it matters: Exactly one page-caching layer should be active. Multiple layers often conflict and can slow the site.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Consolidate to a single page cache (server, CDN, or plugin) and ensure proper purge/invalidation on deploys.

" }, "bad": { "body_html": "

Action (conflicting/missing): Remove duplicate layers and enable one well-supported cache; verify cache headers and hit ratios.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to rationalize caching plugins

  1. List all cache-related plugins detected by Scope and confirm which ones are truly necessary.
  2. Determine whether your host or CDN already performs page caching at the edge.
  3. Disable overlapping cache plugins, keeping only the one that best integrates with your host/CDN.
  4. After each change, clear caches and verify logins, personalized content, and admin pages behave correctly.
  5. Document your chosen caching strategy so future changes don’t accidentally reintroduce conflicts.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "performance", "metric_id": "cache_plugins" } } }, "seo": { "indexing_allowed": { "metric_key": "seo.indexing_allowed", "title": "Search Engine Visibility", "summary": { "html": "

Description

Whether WordPress is set to discourage search engines (blog_public).

Why it matters: Accidentally blocking indexing on production tanks discoverability. Ensure indexing is allowed unless intentionally private.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: If the site is public, uncheck Discourage search engines in Settings → Reading.

" }, "bad": { "body_html": "

Action (blocked indexing): Disable the discourage setting; remove any noindex directives; resubmit sitemaps in Search Console.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to fix search engine visibility

  1. In WordPress, go to Settings → Reading.
  2. Locate Search engine visibility and ensure Discourage search engines from indexing this site is unchecked for public sites.
  3. Check for noindex meta tags in your SEO plugin settings for key pages.
  4. Update and resubmit your sitemap in Search Console or your preferred search tools.
  5. Monitor indexing status over time to confirm recovery.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Robots rules and meta tags can be cached aggressively. After changing noindex/index settings or robots.txt, purge caches (and any CDN) before relying on this tile, and remember that search engines may also cache older directives.

", "links": [], "titleBadge": null, "meta": { "section": "seo", "metric_id": "indexing_allowed" } }, "robots_txt_present": { "metric_key": "seo.robots_txt_present", "title": "robots.txt", "summary": { "html": "

Description

A file that suggests crawl rules to search bots.

Why it matters: Can guide or inadvertently block crawling. Keep it minimal; don’t rely on it for sensitive content.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Ensure robots.txt isn’t blocking key paths; reference sitemap URL.

" }, "bad": { "body_html": "

Action (overblocking/missing): Add a minimal robots.txt and remove broad Disallow lines that block content.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to manage robots.txt

  1. Check /robots.txt in a browser to see the current contents.
  2. For simple setups, use your SEO plugin or host to edit robots.txt rather than maintaining it manually on disk.
  3. Avoid broad Disallow: / directives on production unless the site is intentionally private.
  4. Add a Sitemap: line pointing to your primary sitemap URL.
  5. After changes, re-fetch robots.txt in Search Console if needed.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Some hosts/CDNs serve a generated /robots.txt that can be cached separately from WordPress. If you’ve edited robots rules and Scope still shows the old version, bypass the CDN or clear caches and fetch robots.txt directly from the origin.

", "links": [], "titleBadge": null, "meta": { "section": "seo", "metric_id": "robots_txt_present" } }, "sitemap_present": { "metric_key": "seo.sitemap_present", "title": "Sitemap", "summary": { "html": "

Description

An XML index of site URLs for search engines.

Why it matters: A well-formed sitemap accelerates discovery of new content. Ensure it’s reachable and up to date.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Enable and expose a sitemap (core or SEO plugin); link to it in robots.txt.

" }, "bad": { "body_html": "

Action (missing/broken): Fix sitemap generation; ensure HTTP 200 and correct URLs; submit in Search Console.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to ensure a healthy sitemap

  1. Enable XML sitemaps either from WordPress core or your SEO plugin (Yoast, Rank Math, etc.).
  2. Verify the sitemap URL returns HTTP 200 and lists the expected content types (posts, pages, key taxonomies).
  3. Link to the sitemap from robots.txt.
  4. Submit the sitemap URL in Search Console and monitor for errors.
  5. Check that new content appears in the sitemap soon after publishing.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: XML sitemaps may be cached by SEO plugins, page caches, and CDNs. After enabling or changing sitemaps, clear plugin/page/CDN caches and then re-run the report to confirm the new sitemap is what search engines will see.

", "links": [], "titleBadge": null, "meta": { "section": "seo", "metric_id": "sitemap_present" } }, "home_title_present": { "metric_key": "seo.home_title_present", "title": "Homepage Title", "summary": { "html": "

Description

Presence of a document <title> on the homepage.

Why it matters: Essential for SEO and SERP snippets. Ensure unique, descriptive titles.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Define a unique, concise homepage <title> via theme/SEO plugin.

" }, "bad": { "body_html": "

Action (missing): Implement a <title> tag immediately; verify it renders server-side.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to set your homepage <title>

  1. Open your SEO plugin’s settings for the homepage (or the page set as Front page under Settings → Reading).
  2. Define a concise, descriptive title that includes your brand and primary topic.
  3. Aim for a reasonable length (rough guideline: 50–60 characters) to prevent truncation in SERPs.
  4. Save changes and view the page source to confirm the title tag is output.
  5. Use Search Console’s URL inspection tool to request a re-crawl if you just fixed a missing title.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "seo", "metric_id": "home_title_present" } }, "home_description_present": { "metric_key": "seo.home_description_present", "title": "Meta Description", "summary": { "html": "

Description

Presence of a meta description on the homepage.

Why it matters: Improves click-through from SERPs. Keep to ~150–160 chars and unique per page.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Add a concise, compelling description via SEO plugin; avoid duplication.

" }, "bad": { "body_html": "

Action (missing): Your homepage doesn't define a <meta name=\"description\">. Without one, search engines may pull arbitrary text from the page instead. Add a description via your SEO plugin now.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to set your homepage meta description

  1. In your SEO plugin, edit the homepage’s meta description field.
  2. Write a human-friendly summary of what your site offers, targeted at searchers deciding whether to click.
  3. Keep it roughly 150–160 characters and avoid keyword stuffing.
  4. Save changes and confirm a <meta name=\"description\" ...> tag appears in page source.
  5. Monitor CTR in Search Console to see whether the new description is effective.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "seo", "metric_id": "home_description_present" } }, "canonical_consistent": { "metric_key": "seo.canonical_consistent", "title": "Canonical URLs", "summary": { "html": "

Description

Whether home_url and site_url align (scheme/host).

Why it matters: Mismatches cause duplicate content, session issues, and confusing redirects. Standardize to a single canonical host.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Align home_url and site_url to a single canonical host (www vs non-www) and scheme.

" }, "bad": { "body_html": "

Action (mismatch): Fix URLs in Settings → General, update redirects, and clear caches to prevent duplication and login issues.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to fix canonical consistency

  1. Decide on a single canonical base domain (with or without www) and HTTPS everywhere.
  2. Set WordPress Address and Site Address in Settings → General to that canonical URL.
  3. Configure 301 redirects from any alternate hosts (non-www to www, HTTP to HTTPS) at the server or CDN level.
  4. Ensure your SEO plugin outputs canonical tags that match the chosen base.
  5. Clear caches and verify that all entry points redirect to the canonical host/scheme.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": "Inferred Signal", "meta": { "section": "seo", "metric_id": "canonical_consistent" } }, "permalink_structure": { "metric_key": "seo.permalink_structure", "title": "Permalink Structure", "summary": { "html": "

Description

The URL pattern used for posts (e.g., /%postname%/).

Why it matters: Human-readable permalinks improve UX and SEO. Avoid query-string-only structures in production.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Switch to a readable structure like /%postname%/ in Settings → Permalinks.

" }, "bad": { "body_html": "

Action (default query IDs): Change to a human-readable structure and flush rewrites; update internal links if needed.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to change permalink structure safely

  1. In Settings → Permalinks, choose a human-readable structure like /%postname%/.
  2. Before changing on a long-lived site, map important old URLs to new ones with redirects to preserve SEO.
  3. After saving, WordPress will flush rewrite rules automatically (you can also do this via flush_rewrite_rules() or WP-CLI).
  4. Test a sample of older URLs and confirm redirects behave as expected.
  5. Update any hard-coded internal URLs in templates or content if necessary.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "seo", "metric_id": "permalink_structure" } }, "homepage_type": { "metric_key": "seo.homepage_type", "title": "Homepage Type", "summary": { "html": "

Description

Whether the homepage shows a static page or latest posts.

Why it matters: Affects site architecture and internal linking. Choose based on content strategy.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Ensure the chosen homepage type aligns with SEO strategy and internal linking.

" }, "bad": { "body_html": "

Action: Reconfigure home display to match business goals; adjust menus and redirects accordingly.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to choose homepage behavior

  1. Go to Settings → Reading.
  2. Choose between Your latest posts or A static page depending on your content strategy.
  3. If using a static page, set both the Homepage and Posts page (blog index) appropriately.
  4. Check menus and internal links to ensure they still point to the right home and blog URLs.
  5. Review your homepage structure to ensure it highlights important content for both users and search engines.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "seo", "metric_id": "homepage_type" } } }, "config": { "debug_enabled": { "metric_key": "config.debug_enabled", "title": "Debug Mode", "summary": { "html": "

Description

Whether WP_DEBUG is enabled.

Why it matters: Don’t expose debug output on production. Use WP_DEBUG_LOG to log privately when needed.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Turn off WP_DEBUG_DISPLAY in production; keep WP_DEBUG_LOG on if investigating issues.

" }, "bad": { "body_html": "

Action (debug visible): Disable debug display immediately; move to file logging; remove error output from public pages.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to configure debug mode safely

  1. Open wp-config.php in a safe editor.
  2. On production, ensure WP_DEBUG is true only if you route errors to logs, not the browser.
  3. Set WP_DEBUG_DISPLAY to false and WP_DEBUG_LOG to true to log privately.
  4. Confirm display_errors is disabled at the PHP level for production.
  5. Monitor logs periodically and rotate/clean them so they don’t grow indefinitely.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "debug_enabled" } }, "cron_disabled": { "metric_key": "config.cron_disabled", "title": "WP-Cron Disabled", "summary": { "html": "

Description

DISABLE_WP_CRON toggles WordPress’s internal cron triggers.

Why it matters: On high-traffic sites, disable WP-Cron and run a real system cron hitting wp-cron.php for reliability.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: If disabled, ensure a system cron calls wp-cron.php regularly; otherwise enable WP-Cron.

" }, "bad": { "body_html": "

Action (jobs failing): Re-enable WP-Cron or set up a reliable system cron; verify scheduled tasks run.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to manage WP-Cron vs system cron

  1. Check wp-config.php for DISABLE_WP_CRON.
  2. If it is true, configure a real system cron (via hosting panel or crontab) to call wp-cron.php every few minutes.
  3. If you cannot set up system cron, consider leaving DISABLE_WP_CRON as false so normal traffic triggers events.
  4. Use a cron inspector plugin or WP-CLI to verify events are running on schedule.
  5. Adjust frequency if you see either too many overlapping cron runs or long gaps.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "cron_disabled" } }, "active_theme": { "metric_key": "config.active_theme", "title": "Active Theme", "summary": { "html": "

Description

The theme currently rendering your site.

Why it matters: Theme quality drives performance and security posture. Keep child/parent themes updated.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Update theme and dependencies; remove unused parent/child themes.

" }, "bad": { "body_html": "

Action (outdated/vulnerable): Patch or switch themes; apply a child theme for customizations to enable safe updates.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to evaluate your active theme

  1. In Appearance → Themes, confirm which theme is active and whether it is a child or parent theme.
  2. Check for available updates for both the active theme and any parent theme.
  3. Review your customizations: if modifications are made directly in the parent theme, migrate them into a child theme.
  4. Test alternative themes on a staging site if performance or maintainability is a concern.
  5. Document any theme-specific dependencies (page builder, custom blocks) before making large changes.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "active_theme" } }, "active_theme_version": { "metric_key": "config.active_theme_version", "title": "Theme Version", "summary": { "html": "

Description

Version of the active theme.

Why it matters: Track against changelogs and security notices; update regularly.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Update to the latest compatible version and test templates.

" }, "bad": { "body_html": "

Action (behind/known issues): Update urgently; if blocked by custom code, migrate overrides to a child theme.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to keep the theme version current

  1. From Appearance → Themes, click on your active theme and review version and changelog.
  2. Check the vendor’s site or marketplace for release notes, especially security fixes.
  3. Apply theme updates in a staging environment if you rely on heavy customizations.
  4. After updating, test templates, widgets, and key layouts for regressions.
  5. Repeat on production once you are confident the update is safe.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "active_theme_version" } }, "debug.constants": { "metric_key": "config.debug.constants", "title": "Debug Constants", "summary": { "html": "

Description

Snapshot of WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, SCRIPT_DEBUG, and DISALLOW_FILE_EDIT.

Why it matters: Production should generally have display off, logging on (to file), and file edit disabled in the admin.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Set DISALLOW_FILE_EDIT true; keep display off; log to file for troubleshooting.

" }, "bad": { "body_html": "

Action (unsafe): Disable in-admin file editing and public error display immediately; enable private logging.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to harden debug-related constants

  1. Open wp-config.php and locate WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, SCRIPT_DEBUG, and DISALLOW_FILE_EDIT.
  2. Set DISALLOW_FILE_EDIT to true on production to block editor-based code edits.
  3. Ensure public debug display is off (WP_DEBUG_DISPLAY false) while logging to a file for troubleshooting.
  4. Use SCRIPT_DEBUG only temporarily when debugging asset issues.
  5. Re-run the report to confirm constants now match your production policy.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "debug.constants" } }, "email_deliverability": { "metric_key": "config.email_deliverability", "title": "Email Deliverability", "summary": { "html": "

Description

Checks whether an SMTP/transactional email plugin is active and the last test email status.

Why it matters: WordPress uses the server's mail() function by default, which often fails or lands in spam. Broken email impacts user registrations, password resets, orders, and alerts.

Good to know: Popular SMTP options include WP Mail SMTP, FluentSMTP, and Post SMTP. They integrate with providers like SendGrid, Mailgun, Postmark, and Amazon SES.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Consider installing an SMTP plugin to improve email reliability. Send a test email to verify delivery is working.

" }, "bad": { "body_html": "

Action: Email test failed or no SMTP helper detected. Fix SMTP credentials or install a plugin to prevent email delivery issues.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to set up reliable email for WordPress

  1. Choose an SMTP plugin
    Popular free options: WP Mail SMTP, FluentSMTP, Post SMTP. All support major providers.
  2. Select a transactional email provider
    Options include SendGrid, Mailgun, Postmark, Amazon SES, or your host's SMTP. Free tiers often cover small sites.
  3. Configure credentials
    Enter API key or SMTP credentials in the plugin settings. Most plugins have a setup wizard.
  4. Set up DNS records
    Add SPF, DKIM, and optionally DMARC records to your domain. The plugin or provider usually provides these.
  5. Send a test email
    Use the button below or your SMTP plugin's test feature. Check spam folders and email headers if delivery fails.

Note: Email logging helps debug issues—enable it if your plugin offers it.

", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "email_deliverability" } }, "backup": { "metric_key": "config.backup", "title": "Backups", "summary": { "html": "

Description

Detection of common backup plugins and last-run signals (if available).

Why it matters: Offsite, frequent, tested backups are your safety net. Verify restores periodically.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: Ensure nightly offsite backups for files and DB; test a restore quarterly.

" }, "bad": { "body_html": "

Action (no recent backups): Enable daily offsite backups now and perform a test restore.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to verify and improve backups

  1. Identify which backup solution is currently in use (plugin, host-level, or external service).
  2. Confirm backup frequency, retention period, and whether both files and database are covered.
  3. Run a manual backup and ensure it completes without errors.
  4. Perform a test restore in a staging environment to validate that backups are actually usable.
  5. Document how to initiate restores and who is responsible during an incident.
", "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "backup" } }, "maintenance_mode": { "metric_key": "config.maintenance_mode", "title": "Maintenance Mode", "summary": { "html": "

Description

Presence of .maintenance indicates WordPress maintenance mode.

Why it matters: Should be temporary during updates. If it persists, an update likely failed—remove the flag to restore access.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": "

Action: If unexpected, remove .maintenance; re-run the last update safely.

" }, "bad": { "body_html": "

Action (site stuck): Delete .maintenance, clear caches, and complete the failed update manually.

" } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": "

How to resolve stuck maintenance mode

  1. If your site appears stuck in maintenance mode, check the root WordPress directory for a .maintenance file.
  2. Delete the .maintenance file via FTP/SFTP or your file manager.
  3. Clear any caches (plugin, server, CDN) that might be serving cached maintenance responses.
  4. Re-run the previously failing update, ideally in a maintenance window.
  5. Consider using a dedicated maintenance mode plugin for more controlled downtime messaging.
", "warn": null, "bad": null } }, "cache_note_html": "

Cache: Maintenance pages can be bypassed by stale edge or page caches. If you toggle maintenance mode but some users still see normal pages (or vice versa), clear the cache at every layer and confirm that the maintenance response isn’t being cached unexpectedly.

", "links": [], "titleBadge": null, "meta": { "section": "config", "metric_id": "maintenance_mode" } } }, "meta": { "generated_at": { "metric_key": "meta.generated_at", "title": "Generated At", "summary": { "html": "

Description

Timestamp (ISO 8601) for when this report was produced.

Why it matters: Helps you judge data freshness during troubleshooting.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": null }, "bad": { "body_html": null } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": null, "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "meta", "metric_id": "generated_at" } }, "schema_version": { "metric_key": "meta.schema_version", "title": "Schema Version", "summary": { "html": "

Description

Version of the report payload format.

Why it matters: Useful for dashboards/clients that parse the report and need to handle changes gracefully.

", "evergreen": true }, "states": { "default": { "body_html": null }, "warn": { "body_html": null }, "bad": { "body_html": null } }, "how_to": { "evergreen_html": null, "state_overrides": { "default": null, "warn": null, "bad": null } }, "cache_note_html": null, "links": [], "titleBadge": null, "meta": { "section": "meta", "metric_id": "schema_version" } } } }