A weekly website SEO health check is a short, repeatable review that answers one question: can search engines still reach, understand and show my pages, and did anything change that I didn't intend? It is a monitoring routine, not an optimisation project. Its job is to help you look for breakage early: a page accidentally blocked from indexing, a new article that never went live, a template change that wiped out titles, or a sudden drop in impressions that deserves investigation.
This guide gives you a step-by-step checklist you can run yourself with free tools (a browser and Google Search Console), a triage table for what to do when something looks wrong, and a simple log format so each week's check builds on the last. Verify each step against your own site and data, and treat the Search Console steps as prompts to look at the information your own account shows, since the exact screens and labels may differ from what is described here.
What a weekly check is for (and what it isn't)
Different review rhythms suit different problems. One way to separate them:
- Weekly: look for breakage and unintended change. Is the site up? Are new pages live and indexable? Did anything in Search Console change sharply?
- Monthly or per publishing cycle: review performance. Which pages gained or lost clicks? Which queries are worth a content update?
- Occasionally: strategic work. Keyword planning, site structure, a full content audit.
Keeping these apart matters because a weekly check that turns into a performance deep dive is unlikely to keep getting done. The weekly check should be short enough that you will actually repeat it. If a finding needs real investigation, log it and schedule that work separately.
The checklist
Work through these in order. Each step has an input (where to look) and an observable result (what "healthy" looks like).
1. Confirm the site and key pages load
Input: your homepage, your main service or product page, and your signup, booking or contact page.
Healthy result: each page opens without an error, shows the expected content, and the conversion path (form, button, checkout link) works.
This sounds basic, but a page that returns an error gives searchers nothing to open, and a broken conversion page wastes whatever traffic you do earn. Open the pages in a private browser window so you see what a new visitor sees, not a cached or logged-in version.
2. Check that new and updated pages are actually live
Input: the list of pages you published or edited since last week.
Healthy result: every one opens at its public address, shows the final text (not a draft or placeholder), and has the title you intended.
A publishing system can report success while the public page differs from what you expected, for example a draft state, a stale cache, or a failed deploy on a GitHub-based site. Opening the real URL is the direct way to settle it. If you publish through an automated pipeline, verify this step carefully, because nobody is looking at the page at the moment it goes out.
3. Look for accidental indexing blocks
Input: the page source or an inspection tool for your key pages, plus your robots.txt file at yourdomain.com/robots.txt.
Healthy result: pages you want found do not carry a noindex directive, are not disallowed in robots.txt, and point to the correct canonical address.
Three things to look for. First, a staging or "discourage search engines" setting that stays switched on after launch or a migration. Second, a plugin, theme update or deploy that changes robots rules or adds a noindex tag to a template. Third, a canonical tag that points to a different page than intended, which tells search engines to treat another URL as the main version. None of these is visible to a human visitor, because the site looks fine. They are cheap to check, so they belong in the weekly pass.
4. Review Search Console's indexing information
Input: whatever indexing or page-status information your Google Search Console property shows for your site.
Healthy result: the number of indexed pages moves in a direction you can explain, and any reasons given for pages that are not indexed are ones you expect (for example, deliberate redirects or pages you excluded on purpose).
You are not looking for zero excluded pages. Some exclusions may be intentional. You are looking for change: a new reason, a jump in the count of a particular status, or a page you care about appearing in an unexpected list. Compare this week's view with the previous entry in your log (see below). Without a record of last week, "is this normal?" has no answer.
5. Scan Search Console performance data for sharp movement
Input: your clicks, impressions and average position data, comparing a recent period with an equally long earlier period.
Healthy result: clicks, impressions and average position for your important pages and queries are within a range you can explain.
Compare periods of equal length rather than reading a single period in isolation. At this stage you are not optimising; you are flagging anything that moved sharply so you can ask what changed. Useful questions:
- Did impressions fall across the whole site, or for one page or one query group? A site-wide drop may point toward a technical or sitewide cause; a single-page drop may point to that page.
- Did a page you edited last week move afterwards? If so, note the edit and the date next to the movement.
- Did a new article start appearing for any queries at all? Appearing for queries suggests it is indexed, even if positions are low.
If your data shows only a small fluctuation in one week, note it and see whether the direction continues before acting.
6. Check Search Console for notices
Input: any messages, security notices or manual-action notices your Search Console property shows.
Healthy result: no new notices.
A notice can explain a sudden change, so read it directly rather than relying on a summary. Also confirm that whatever alerts you have set up for your property reach someone who reads them.
7. Spot-check titles, descriptions and headings on new pages
Input: each page published or edited this week.
Healthy result: each page has a distinct title that describes its content, a single clear main heading, and a description that is not a copy of another page's.
Duplicate or missing titles can appear after a theme or template change and affect many pages at once, so check a sample of older pages as well as new ones. This is also a good moment to confirm each new page is linked from somewhere else on your site, such as a relevant existing page or a blog index. A page with no links pointing to it is harder for visitors and crawlers to find.
8. Test for broken links and redirects on pages you touched
Input: the links on new or edited pages, and any URLs you renamed or removed.
Healthy result: internal links open the intended page directly, renamed URLs redirect to their replacements, and no link leads to an error page.
If you renamed or deleted a page this week, test the old address in your browser. A removed page with no redirect sends visitors to an error page.
9. Run a quick mobile and speed spot-check
Input: your key pages opened on a phone, or in your browser's device emulation.
Healthy result: text is readable without zooming, buttons are tappable, nothing overlaps, and pages do not feel noticeably slower than usual.
Keep this to a spot-check. Detailed performance work belongs in a separate project. The weekly purpose is catching regressions, such as a new script, oversized image or plugin that made pages visibly worse since last week.
Triage: what to do when something looks wrong
Use this table as a starting point. It is a set of recommendations for the first diagnostic move, not a guarantee of cause.
| What you see | Possible causes to rule out first | First action |
|---|---|---|
| A new page isn't loading publicly | Publish failed, page left as draft, deploy error, cache | Open the live URL in a private window; check your publishing system's status for that item |
| Page loads but isn't indexed after some time | noindex, robots block, wrong canonical, weak internal linking | Check the page source and robots.txt, then read any reason Search Console reports for that URL |
| Site-wide impressions fall suddenly | Sitewide noindex, robots change, migration issue, server errors, manual action | Check robots.txt, template source and Search Console notices before touching content |
| One page's clicks drop | Page edit, title change, lost links, query intent shift | Compare the page's before/after state against your log of edits |
| Many pages share a title or description | Template or plugin change | Review the template or SEO plugin settings |
| New "not found" or error URLs appear | Renamed pages without redirects, broken internal links | Add redirects and fix the linking page |
The principle behind the table: check the cheapest, most reversible explanations first. A configuration setting is quick to inspect, whereas rewriting content takes longer and will not fix a technical block.
Keep a simple weekly log
A health check is only useful when you can compare it with the previous one. A spreadsheet or document with a row per week is enough. Suggested fields:
- Date of the check
- Pages published or edited, with dates
- Indexed page count and any new non-indexed reasons
- Notable clicks or impressions movement, by site or page
- Any Search Console notices
- Issues found, who owns the fix, and the date resolved
Here is a hypothetical entry to show the format: "Example week: Published two articles; both open correctly. Indexed count unchanged. Impressions flat sitewide. One older service page lost clicks the same week its title was edited. Action: restore the previous title and re-compare next week." The details are invented to illustrate the structure and are not evidence of any outcome.
The edit-date column is the most valuable one. When rankings move, the first thing you need to know is what you changed, and memory is an unreliable record.
Which parts you might automate
This is the author's view, not an established rule. Steps that compare a state against an expectation (is the page live, is a tag present, did a count change) are, in my view, the most natural candidates for automation, because the expected answer is known in advance. Steps that need judgement, such as deciding whether a drop reflects a change in search intent or whether a page deserves a rewrite, are better left with a person.
If you do automate, keep one rule: an automated check should tell you what it looked at and what it found, so you can verify it occasionally yourself. A tool that only reports "all good" gives you nothing to audit.
Where Pentra fits
Pentra is SEO software whose listed features include weekly website SEO health checks and Google Search Console reporting. Those are the two features most relevant to this routine. Pentra's own materials describe its Search Console reporting as showing clicks and positions from your own Search Console data.
The product information available for this article does not spell out which of the checklist steps its weekly health check covers, or what its reports contain beyond that. If you use Pentra, compare what its health check and reporting show against the checklist above, and keep doing by hand any step you can't confirm it covers. The judgement steps stay with you either way: you decide how to respond to a flagged problem, and you should read any Search Console notices directly.
If you want to see how those features work, you can try Pentra.
Common mistakes to avoid
- Turning the check into an optimisation session. Log opportunities and move on; do them in a separate block of time.
- Reacting to a single week of small movement. Note it, and wait to see if the direction continues.
- Checking only new pages. Template and plugin changes can affect old pages too, so sample a few each week.
- Skipping the log. Without last week's record, you can't tell normal variation from change.
- Trusting a publish confirmation instead of the live page. Open the public URL.
- Fixing content when the cause is technical. If a page can't be indexed, better writing won't help until the block is removed.
A minimal version to start this week
If the full list feels like too much, begin with four checks: open your key pages in a private window, open every page you published or edited, read the Search Console indexing information and any notices, and write one line in your log. Add the remaining steps as the routine becomes habitual. A short check you actually repeat is more useful than a thorough one you do once.