198 lines
9.8 KiB
Markdown
198 lines
9.8 KiB
Markdown
## 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 uptime kuma log)
|
|
- 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.*
|