wp-healthcheck/steps.md

## WordPress Site Healthcheck — Technician Guide
### Before You Start

- Confirm you have admin access to the WordPress dashboard and hosting control panel
- Check the client record for any known issues, recent changes, or flags from the previous healthcheck
- Note the current WordPress version, PHP version, and active theme before touching anything

- Install our recovery plugin. This plugin should also step you through what's needed for the healthcheck as well. 
- Make a note of the recovery path in case there is a problem


---

### Step 1 — Take a Full Backup

Before any work takes place, take a complete backup manually. Do not rely on the most recent automated backup.

- Back up both the database and all files (wp-content, wp-config.php, .htaccess)
- Confirm the backup has completed and is accessible/downloadable
- Note the backup location and timestamp in the client record

**If the backup fails or cannot be confirmed, stop. Do not proceed until you have a verified backup.**

---

### Step 2 — Environment Check

Before touching updates, review the hosting environment:

- **PHP version** — check against WordPress requirements and plugin compatibility. Flag if below 8.1. Note if EOL.
- **Disk usage** — flag if over 80% used
- **Error logs** — check the server error log and WordPress debug log if enabled. Note any recurring errors, 500s, or deprecated function warnings
- **wp-config.php** — confirm WP_DEBUG is off on production
- **File permissions** — spot check wp-config.php (should be 640 or 600), wp-content (755), uploads (755)

---

### Step 3 — WordPress Core Update

- Check current version against latest stable release
- If an update is available, apply it
- After update, load the site front-end and wp-admin and confirm both are functioning
- Check the database upgrade prompt — if WordPress prompts to upgrade the database, run it
- Note the version you updated from and to

**Watch out for:** white screen of death post-update, admin redirect loops, missing admin menu items — these usually indicate a theme or plugin conflict with the new core version.

---

### Step 4 — Plugin Updates

- Go to Dashboard → Updates and review all pending plugin updates
- Before updating, note which plugins have updates and what versions they are moving to
- Update plugins one at a time if the site is complex or has many interdependencies; batch update is acceptable for straightforward sites
- After each update (or after a batch), check the front-end and any key functional areas (forms, checkout, membership, etc.)
- Check for any plugins that have been deactivated but not deleted — flag these to the client

**Watch out for:**
- WooCommerce updates — always treat these as high-risk, test checkout flow afterwards
- Page builder updates (Elementor, Divi, Beaver Builder) — can affect layout rendering
- Security plugin updates — confirm they reactivate and are still reporting clean
- Plugins that haven't been updated by their developer in over 12 months — flag as a risk
- Plugins showing "Update unavailable" or removed from the WordPress repository — flag immediately, these can indicate abandoned or compromised plugins

---

### Step 5 — Theme Updates

- Update the active theme if an update is available
- If a child theme is in use (correct practice), the parent theme can be updated safely — confirm child theme is active
- If no child theme is in use and the parent theme has been customised directly, do not update without flagging to the client first — the update will overwrite customisations
- Update inactive themes only if they are legitimate fallback themes (e.g. a default Twenty* theme). Unused themes that serve no purpose should be flagged for removal

**Watch out for:** layout changes post-theme update, broken header/footer, missing custom fonts or colours — indicates customisation was done directly in the parent theme.

---

### Step 6 — Visual and Functional Check

Do a manual walkthrough of the site:

- **Homepage** — load and visually inspect. Check for broken images, layout issues, console errors (open browser dev tools)
- **Navigation** — click through the main menu. Confirm all links resolve correctly, no 404s on primary pages
- **Key pages** — About, Contact, Services or equivalent. Check content renders correctly
- **Contact form** — submit a test entry and confirm it delivers (check spam folder if no delivery). Note which form plugin is in use
- **If WooCommerce** — check shop page loads, a product page loads, add to basket works. Do not need to complete a full test purchase every time unless flagged
- **If membership/login** — confirm login page loads and (if test credentials available) login works
- **Mobile view** — check the homepage and one internal page on a mobile viewport in browser dev tools
- **HTTPS** — confirm the padlock is showing and there are no mixed content warnings
- **Redirects** — confirm www/non-www and HTTP/HTTPS are redirecting correctly to the canonical URL

---

### Step 7 — Performance Check

- Run a quick PageSpeed Insights check on the homepage
- Note the scores (mobile and desktop) in the client record
- Flag if mobile score has dropped significantly since last check (more than 10 points)
- Check that caching is active — if using a caching plugin, confirm it is enabled and not throwing errors
- Check image sizes on the homepage — flag if uncompressed images over 500KB are being served

---

### Step — Google Analytics Check

Confirm the site is still reporting into Google Analytics.

- Confirm a tracking snippet is present on the homepage (view source, look for gtag/GTM/analytics.js)
- Log into Google Analytics and confirm real-time users are being recorded when you load the site
- Confirm the measurement ID on the site matches the client record (G-XXXX for GA4, GTM-XXXX for Tag Manager)
- Check that today has page-view events in the property — flag if traffic has dropped to zero
- Flag if only Universal Analytics (UA-XXXX) is still in use — GA4 has been required since July 2023

**Watch out for:** cookie/consent banners that block the tracker until accepted; caching/optimisation plugins that defer or strip inline scripts.

---

### Step — Google Search Console Check

Confirm the site is still verified and Google can crawl/index it.

- Log into Google Search Console and confirm the property is still verified
- Check the Pages / Coverage report for new indexing errors since the last healthcheck
- Confirm the sitemap is submitted and its "Last read" date is recent
- Skim the Performance report — flag significant drops in impressions or clicks (>25% vs. previous period)
- Check Manual Actions and Security Issues — flag anything that is not "No issues detected"
- Confirm the verified property matches the canonical URL (http vs https, www vs non-www) actually serving

**Watch out for:** a missing verification meta tag doesn't mean unverified — DNS TXT and file-based verification are equally valid.

---

### Step 8 — Security Check

- Confirm the SSL certificate is valid and not expiring within 30 days — flag if so
- Check the WordPress user list — flag any unfamiliar admin accounts
- Check for any recently modified core files if you have file change monitoring in place
- Confirm the login URL is not the default /wp-admin if security hardening was previously applied
- If a security plugin is active, review its dashboard for any flagged issues
- Check that xmlrpc.php is disabled or restricted if not in use

---

### Step 9 — Database

- Run a database optimisation (via WP-CLI: `wp db optimize`, or via a plugin such as WP-Optimize)
- Check for and remove any spam comments if comment moderation hasn't been keeping up
- Check post revisions — if excessive (thousands), note for client discussion on whether a revision limit should be set

---

### Step 10 — Uptime and Availability

- Check uptime monitoring logs if available — note any downtime incidents since the last healthcheck and flag to client if significant
- Confirm the site is resolving correctly on both www and non-www

---

### Step 11 — Small Fixes

Address any small issues found during the check that fall within the ~15 minute threshold:

- Broken internal links on key pages
- Missing alt text on homepage images
- Obvious content errors noticed in passing (broken shortcodes, missing widgets)
- Reactivating a deactivated-but-needed plugin
- Clearing accumulated spam comments

For anything that will take longer, write it up as a separate item to quote for.

---

### Step 12 — Wrap Up and Document

- Log everything done in the client record: versions before and after, any issues found, any fixes applied, anything flagged for follow-up
- Note the date, time taken, and technician
- If using ManageWP or WP Umbrella, generate the client report and review it before sending — make sure it accurately reflects what was done
- Send the client report or file it according to your process
- If anything was flagged that needs a separate quote or client decision, send that communication now rather than leaving it

---

### Quick Reference — When to Stop and Escalate

| Situation | Action |
|---|---|
| Backup cannot be confirmed | Stop. Do not proceed. |
| Site is down before you start | Diagnose and resolve before running updates |
| Core update causes white screen | Restore backup immediately |
| Plugin removed from WP repository | Flag to client before removing |
| Unfamiliar admin user found | Flag to client immediately, do not delete without instruction |
| SSL expiring within 30 days | Escalate for renewal before next healthcheck |
| PHP version EOL | Raise with client as a separate piece of work |

---

*This is intended as a repeatable checklist rather than a rigid script — experienced technicians will move through familiar sites faster, but the sequence and the stop/escalate conditions should be consistent regardless of who runs the check.*