## 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 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.*