# A monthly site health routine, done in 30 minutes > Ten checks in a fixed order, from the certificate to the backup, that catch the problems which quietly cost a site visitors between redesigns, with report links to compare month on month. Updated 2026-09-25 · Workflows & checklists · HTML version: https://getreport.app/guides/monthly-site-health-routine Most sites break slowly. A certificate renewal fails silently, a plugin stops being maintained, a retired product leaves a dead link in the footer, a theme update adds a second of load time. None of it shows on the day it happens, and by the time someone notices, the fix is a project. Thirty minutes a month, in a fixed order, catches nearly all of it while it is still a five-minute job. This guide is that order, with what to do when a step comes back red and a table you can print. ## Quick answer | # | Check | Where | Red means | | --- | --- | --- | --- | | 1 | Certificate and HTTPS | Report, Security module | Renewal is failing; fix today | | 2 | Search Console | Pages, Manual actions, Core Web Vitals | Indexing or a penalty; fix this week | | 3 | Report on the home page and three landing pages | Speed test / SEO audit, compare with last month | Something regressed since the last change | | 4 | Core Web Vitals history | CWV history tool | Real visitors are slower than last month | | 5 | Broken links on key pages | Report, SEO module | Retired pages left behind | | 6 | Updates and abandoned plugins | CMS admin + WordPress Doctor | Known security holes | | 7 | Forms and checkout | By hand | Lost leads or orders | | 8 | Analytics sanity | Your analytics | Tracking or consent broke | | 9 | Backup restore test | Quarterly | The backup is not a backup | | 10 | Write the note | Spreadsheet | Nothing; this is how next month works | ## Why a routine beats a redesign The damage between two redesigns is rarely one big thing. It is a hundred small ones, each one cheap the week it happens and expensive a year later: a broken link that was one edit becomes a migration's worth of 404s; a plugin two years without updates becomes the hole a bot walks through; a slow hero image someone uploaded in March is why the summer campaign converted badly. The redesign then fixes everything at once, at a cost of months, and the slow rot begins again the day after launch. A routine catches each problem while it is small. The order matters: it runs from "visitors cannot reach the site" to "we could do better", so that if you only have ten minutes this month, the ten minutes go where the damage is. And because a getReport link is permanent for 12 months, last month's report is the baseline for this month's; you are comparing, not guessing. ## How getReport checks it > **Free tool:** [Website speed test](https://getreport.app/tools/speed-test): Lighthouse lab results and real-user Core Web Vitals for any page, mobile and desktop, with a filmstrip, a request waterfall and a fix for every slow part. Free, no signup. Every tool runs the same full report; the [speed test](https://getreport.app/tools/speed-test) opens it at the Speed module and the SEO audit at SEO, but all seven modules are there either way. One report per key page per month is the backbone of the routine: ![A full getReport report of the shop's home page: the overall score ring, seven module rings, and the Top fixes list with points and effort for each item](https://getreport.app/guides/img/monthly-site-health-routine/report.webp "The score row and Top fixes are the two-minute read; the rest of the report is for the items you decide to fix.") Four findings do most of the work in a monthly pass: > **Check: Certificate expiry.** When the certificate expires, every browser shows a full-page warning and most visitors leave. Automatic renewals fail silently more often than you would expect. > > 1. Renew the certificate now; with Let's Encrypt, run certbot renew and check the auto-renew job's logs. > 2. Add a monitor so you get an email 14 days before the next expiry. The finding warns below 30 days and fails below 7. Renewals through Let's Encrypt happen every 60 days or so, so a certificate that shows fewer than 30 days has already missed at least one renewal attempt. > **Check: Lighthouse performance score.** This is the number Google's own tools show for your page. It combines five of the lab metrics below (all except TTFB), weighted the way Lighthouse weights them. 90 and above is green. > > 1. Work through the failed metrics and opportunities below in order of points; the score follows. Do not read a single run as a trend; lab scores move a few points between runs. A change of 10 or more from last month is a signal, and the history strip under the score row shows the change since the previous report. > **Check: Broken links.** A link to a 404 page is a dead end for visitors and a wasted crawl for search engines. Old campaign or product pages are the usual cause. > > 1. Update or remove each link listed in the technical detail; redirect the missing pages if they still get visits. > 2. In WordPress, a plugin such as Broken Link Checker finds these site-wide. > **Check: CMS version.** Old CMS versions have published security holes that bots scan for automatically, and the generator tag advertises the exact version to them. > > 1. Back up the site, then update the CMS from its admin dashboard; update plugins and themes at the same time. > 2. Remove the generator tag (WordPress: remove_action('wp_head', 'wp_generator') in functions.php). The last one reads the generator tag, so it only fires when the CMS announces its version (WordPress, Joomla and Drupal do by default). On WordPress the WordPress Doctor panel adds two more: plugins not updated in over two years, and plugins closed on wordpress.org. ## Step by step ### 1. Certificate and HTTPS (2 minutes) Open the site over `https://` in a private window; the lock should be there and no warning. Then open last month's report and press **Re-run** on the home page (or run a new one), and read the Security module: certificate days, chain validates, HTTP redirects to HTTPS, no mixed content. **Red:** renew now. With Let's Encrypt on your own server, `certbot renew` and then read why the automatic job failed (the log usually says: a DNS change, a moved web root, a firewall). On a managed host, the SSL page in the hosting panel has a renew button; if it fails, open a ticket the same day. [Certificate expiry: automate it, then monitor it](https://getreport.app/guides/certificate-expiry-automate-it-then-monitor-it) covers the causes. ### 2. Search Console (5 minutes) Three screens, in this order: 1. **Manual actions** and **Security issues**: both should say "No issues detected". Anything else is the most urgent item of the month. 2. **Pages** (indexing): look at the "Why pages aren't indexed" table for rows that grew since last month. "Excluded by noindex tag" or "Blocked by robots.txt" on pages you want indexed means a setting changed; "Not found (404)" growing means broken links or removed pages. 3. **Core Web Vitals**: the count of poor URLs on mobile. A jump usually lands on a group of similar pages, which tells you which template to look at in step 3. Also check the sitemap under Indexing → Sitemaps: "Success" with a recent read date, and roughly the number of pages you expect. ### 3. The report, on the same four pages (8 minutes) Run the home page, the top two or three landing pages from analytics, and one template page (a product, an article) that stands for the rest. Use the same pages every month, on mobile. For each, compare with last month's link: - The **history strip** under the score row shows the change since the previous report for Overall, Speed, SEO and Security. Green deltas are good news; a red one of 5 or more points is worth opening. - **Top fixes** lists the five findings that cost the most points. If the list is the same as last month, nothing new broke and the open items are the known backlog. A new entry at the top is this month's finding. - Skim the failed items in Security and SEO. A new `noindex`, a canonical pointing elsewhere or a missing HSTS header after a host change are the ones that hurt most and are easiest to miss. How to read the report in detail is in [how to read a getReport report](https://getreport.app/guides/reading-a-getreport-report). Fresh runs are limited to 10 per 10 minutes and 50 a day per connection, and 5 per hour per target site; four pages a month is well inside that, and re-opening an existing report link never counts. ### 4. Core Web Vitals history (3 minutes) The [Core Web Vitals history tool](https://getreport.app/tools/cwv-history) shows up to 40 weekly points of real-user LCP, INP and CLS for the whole site. You are looking for one thing: did a line move in the last four weeks? A line that crossed from green into amber has a date, and that date sits within a few weeks of a change you made. Sites with too few Chrome visitors have no data here; use the lab numbers in step 3 instead. The full reading is in [Core Web Vitals history: 40 weeks of real-user data](https://getreport.app/guides/core-web-vitals-history-40-weeks). ### 5. Broken links on the key pages (3 minutes) The reports from step 3 already checked every link on those four pages. Open the broken-links finding in the SEO module on each; the technical detail lists the URL, the status and the anchor text. Fix the internal ones now (update the link, or add a redirect if the old page had traffic); note external ones for a quieter day. The full method is in [how to find and fix broken links](https://getreport.app/guides/find-and-fix-broken-links). Once a quarter, run the [broken link checker](https://getreport.app/tools/broken-link-checker) on a few old pages too: resource lists, the oldest posts, the footer's target pages. Those rot fastest. ### 6. Updates and abandoned plugins (5 minutes) In the CMS admin: core, plugins and theme updates pending. On WordPress, Dashboard → Updates lists all three. Before updating, take a backup (most hosts have a one-click backup on the same page as the restore); then update core first, plugins second, theme last, and open the home page and one product or article page after each round. Read the WordPress Doctor panel in the report too. A plugin that has not been updated in two years or has been closed on wordpress.org will not show in the Updates screen, because there is nothing to update to; that is the whole problem. Replacements are the subject of [abandoned and closed plugins: how to find replacements](https://getreport.app/guides/abandoned-and-closed-plugins-how-to-find-replacements). PHP and the server are the host's side: the hosting panel shows the PHP version, and a version past its end of life gets no security fixes. Moving up one version is usually a dropdown and a test. ### 7. Forms and checkout (3 minutes) Nothing in a report can tell you that the contact form stopped delivering. Send one test through every form that matters (contact, quote, newsletter) and confirm the message arrives where it should. On a shop, put one item in the cart and go as far as the payment page; on a real order, refund the test afterwards. A form that silently fails after a plugin update is one of the most expensive faults a site can have, and one of the cheapest to check. ### 8. Analytics sanity (2 minutes) Open the last 30 days against the 30 before. Three things break tracking without anyone noticing: a consent banner update that stops the tag firing after "accept", a theme change that dropped the tracking snippet, and a tag manager container published with an error. A sudden drop that lines up with a deploy date is tracking, not traffic. The report's Best practices module notes whether an analytics tag and a consent banner were seen on the page, which is a quick way to confirm the snippet is still there. ### 9. Backup restore test (quarterly, 10 minutes) A backup that has never been restored is a hope. Once a quarter, restore the latest backup to a staging copy (most managed hosts offer this) or download it and check that it contains the database and the uploads folder, with dates from this week. If the host does the backups, find the restore button before you need it. ### 10. Write the note (2 minutes) One row per month in a spreadsheet: the date, the four report links, the overall and Speed scores from each, what was red, what you fixed, what is next. Next month, this row is your baseline, and after a year it is the site's medical history: you can see the month the score dropped and what changed that month. A row that works: ```text 2026-09 | home https://getreport.app/r/… (82, speed 71) | landing /pricing … (79, speed 66) | red: certificate 12 days, 3 broken links on /resources | fixed: renewed cert (cron path), 3 links updated | next: hero image on /pricing (LCP 3.9 s), Elementor update pending ``` ## When something is red - **Certificate, HTTPS, security failures:** today. See step 1 and [SSL/TLS checks that matter](https://getreport.app/guides/ssl-tls-checks-that-matter). - **Manual action or security issue in Search Console:** this week; start with [is my website hacked?](https://getreport.app/guides/is-my-website-hacked). - **Speed dropped 10+ points on a page:** open Top fixes on that page; the new entry names the cause. LCP is usually an image; Total Blocking Time is usually a new script. - **Broken links, updates, abandoned plugins:** this month, in the batch. - **Anything that needs a developer:** open the fixes view (the report link plus `/fixes`), copy the Markdown into a ticket, and send the report link with it. [Send the fixes to your developer](https://getreport.app/guides/send-fixes-to-your-developer) shows the format. ## Platform notes ### WordPress Steps 6 and 9 are where WordPress differs. The Updates screen covers core, plugins and themes; the WordPress Doctor panel covers what the Updates screen cannot see. Keep the number of plugins in view: each update round is a chance for one of them to break a form, which is why step 7 follows step 6. ### Shopify, Wix, Squarespace The platform renews the certificate, updates the software and keeps the backup, so steps 1, 6 and 9 shrink to a glance. Steps 2, 3, 5, 7 and 8 are unchanged, and step 7 is more important, not less: apps and theme updates change checkout behaviour without notice. ### Static sites No updates screen, but the build's dependencies age the same way. Once a month, rebuild with updated packages and redeploy; the report's headers and caching checks confirm the host configuration survived the deploy. ## Verify - The spreadsheet has this month's row with four report links, and each link opens. - On each new report, the history strip shows the change since last month, and nothing you fixed last month is back in Top fixes. - Search Console shows no manual action, and the sitemap was read within the last few days. - A test message arrived from every form. ## Common mistakes - **Running different pages each month.** Scores differ between pages more than between months. Fix the four pages and keep them. - **Reading a 3-point speed change as a trend.** Lab scores vary between runs. Look for 10 points, or at the CWV history for what real visitors saw. - **Updating everything, then checking nothing.** Step 7 exists because updates break forms. Test after updating, not next month. - **Trusting the backup because it says "completed".** Restore it once a quarter. - **Skipping the note.** Without last month's links there is no comparison, and the routine becomes a monthly opinion about the score.