Ever run into this: your site’s indexed pages suddenly start dropping, rankings begin to fluctuate, first instinct is to blame an algorithm update, you investigate all over and finally find it was actually a basic thing quietly breaking — robots misblocking, an expired certificate, a dead sitemap, a template change crashing the whole site into 5xx. Running a 15-minute checklist regularly catches most of these low-level failures before the impact spreads, and saves you the panic of putting out fires later.
This checklist leans toward “quick troubleshooting” rather than deep audit — suited to a routine pass monthly or after each release. First confirm the whole site opens normally, the certificate hasn’t expired, no large-scale 5xx; then use the URL inspection tool to confirm important pages are crawlable and indexable, not noindexed; sitemap and robots.txt must be accessible with correct content — those are the two most overlooked spots; finally run PageSpeed on the homepage and core pages, LCP shouldn’t cross the 2.5-second line.
Step one: confirm it’s accessible
Open the homepage and a few inner pages with a browser and a headless tool, confirm no large-scale 5xx. Check the SSL certificate expiry date while you’re at it — an expired certificate makes browsers block the whole site outright, crawlers stop crawling too, and this kind of failure often happens in the early morning, so by the time you find out at sunrise it’s been down for hours, losing indexing and visitors together.
Then check whether DNS resolution is normal — A/AAAA records shouldn’t point to an old IP or a decommissioned load balancer. Also spot-check opening on mobile networks; many failures only appear on specific carriers or regions, desktop access being fine doesn’t mean the whole network is fine. Accessibility is the foundation — if the foundation cracks, everything after is wasted, even the best content can’t get out. Be strict in troubleshooting.
Step two: confirm it’s crawlable
In GSC, use the “URL Inspection” tool to test a few core URLs, see whether “Google can crawl” is green. If it shows blocked by robots, eight times out of ten there’s an extra Disallow line in robots.txt, or a page got noindexed by mistake. This kind of error is quick to fix, but costly if discovered late — a whole batch of pages may already have fallen out of the index, rankings crashing with it.
At the same time check whether robots.txt itself is accessible and the syntax is right. One stray backslash or a case error can lock an entire directory out. The crawl layer is strongly related to crawl budget optimization: door open correctly, budget gets spent where it counts; door open wrong, crawlers can’t even reach the homepage, and all subsequent optimization loses its precondition.
Step three: confirm it’s indexable
In GSC’s “Pages” report, watch whether the number of indexed pages drops abnormally. If a batch of pages falls from “Valid” to “Excluded,” click into the reason: duplicate content, canonical conflict, or redirected away by canonical. Short-term index fluctuation is normal; two consecutive weeks of decline means chase the cause — don’t wait until rankings drop to look back, recovery takes longer then.
Sites with too-deep architecture, deep pages often go undiscovered long-term. Against the principles of flat site architecture, confirm important pages are no more than three or four clicks from the homepage; otherwise even if indexable, weight can’t flow down — indexed but hard to rank, wasting the crawl budget you captured. Note down architecture issues while you’re at it.
Step four: run a speed check
Use PageSpeed Insights to test the homepage and one typical article, focus on the three metrics LCP, CLS, INP. LCP over 2.5 seconds, CLS over 0.1, INP over 200 milliseconds — record them in your todo. Speed checks don’t need deep digging every time; first flag the over-limit items, handle them in a dedicated pass later — more efficient than cramming at the last minute, and easier to track.
Test mobile and desktop separately — many sites pass on desktop and fail on mobile, and mobile experience now directly affects rankings. Record the over-limit URLs and specific metrics, hand them to front-end for scheduling — far more useful than vaguely saying “the site is a bit slow,” and it makes later acceptance checkable against the same set of numbers, avoiding arguments and unverifiable claims.
Turn the checklist into a habit
The checklist’s biggest value is “routine,” not one-off. Store it as a team-shared checklist, must-run after releases and monthly, whoever runs it signs off. That way failures get caught on the day they happen, instead of someone remembering to check two weeks after rankings drop — by then recovery costs and user loss have already happened, far more expensive than one routine check.
Keep screenshots or brief records each execution, and in three months you have a trend baseline. Say the homepage LCP creeps from 1.8 seconds to 2.4 seconds — this “boiling frog” style degradation can only be caught early through continuous records. By the time it crosses 2.5 seconds, rankings are usually already hurt, and recovering takes weeks again — not worth it.
Figure: Website Health Check List Key Points (compiled by YunyingGO)
| Check item | Tool | Pass line |
|---|---|---|
| Accessible | Browser/SSL check | No 5xx, cert valid |
| Crawlable | GSC URL Inspection | Shows crawlable |
| Indexable | GSC Pages report | No abnormal drop |
| Speed | PageSpeed | LCP<2.5s |
Commonly missed items
What the checklist misses most is “changed items”: a page that was fine yesterday can turn into 5xx today because of a failed deployment; a column added last week forgot to be allowed in robots. So a checkup isn’t about static config, it’s about “whether anything changed since last time” — especially on release day, new code most easily introduces regression failures.
Another missed point is mobile vs desktop differences, and DNS differences across regions. Testing on one machine, one network means you’ve only seen one side of the site. When conditions allow, test on a different network and device — it catches those “works fine on my computer” ghost failures, avoiding misjudging the site as healthy.
Automation suggestions
When the site grows and releases become frequent, purely manual checkups leak. You can script a few of the checks: curl to test key URL status codes, call the GSC API to pull index counts, run one PageSpeed, summarize results into a weekly report. Humans only review anomalies, routine parts go to machines — no extra burden, and frequency is maintained. Put the certificate expiry date on the calendar with a two-week warning; build a review mechanism for “Excluded” indexed pages; keep screenshots each checkup to compare trends.
