Monthly and Quarterly SEO Health Check
Run a monthly and quarterly SEO health check that catches regressions in indexing, performance, schema, links, freshness, and page specifications at scale.
An SEO health check is a scheduled test for regression: a condition that used to meet an agreed standard and no longer does. It is not a miniature strategy project and it is not a dashboard tour. The review protects the technical and editorial system already built, catches faults before they spread, and turns every material exception into owned work.
Checklist: Monthly and Quarterly SEO Health Check. Timebox: 2–4 hours monthly; one working day quarterly, plus separately estimated remediation. Owner: the SEO lead is accountable; analytics, engineering, content, and product owners supply evidence and accept actions in their areas.
Run the monthly check on the same business day each month, after data for the previous complete month has settled. Run the quarterly check after every third monthly check. Keep release freezes, migrations, security incidents, and urgent legal or factual corrections on their own response cadence; a calendar must never delay a known critical fault.
Why this phase, and why here
This checklist sits inside continuous refresh and iteration because maintenance requires a stable reference point. It consumes the crawl rules, indexable URL set, templates, and thresholds from the technical baseline audit ; the ownership, purpose, and review dates from the content inventory and audit ; plus release annotations, Search Console data, analytics, monitoring history, and accepted exceptions.
Run it after those sources exist. Without a baseline, a reviewer cannot tell a regression from a long-standing defect. Without an inventory, “2,000 stale URLs” has no business context: the count might describe low-risk archives or every revenue page. Without release history, a sudden indexation drop generates speculation instead of a testable link to a deployment.
The monthly and quarterly split exists because failures move at different speeds. Index blocks, template errors, broken internal links, and performance regressions can damage a large cohort within days, so the monthly pass is narrow, repeatable, and sensitive. Ownership drift, outdated specifications, long-tail freshness, and weak sampling need more evidence and cross-functional attention, so the quarterly review goes deeper. Running the full audit monthly wastes capacity and encourages superficial completion; running only quarterly lets fast regressions persist too long.
Inputs and outputs
| Direction | Item | Required content | Acceptance condition |
|---|---|---|---|
| Input | Signed baseline | Eligible indexable URL count, priority cohorts, templates, Web Vitals bands, schema expectations, link-error baseline, and freshness rules. | Values have a measurement date, source, scope, and owner. |
| Input | Current evidence | Complete-month search data, URL inspections, crawl results, field performance, schema validation, sitemap history, inventory, and release annotations. | Filters, collection times, exclusions, and missing coverage are visible. |
| Input | Change register | Deployments, CMS or template edits, migrations, redirects, tracking changes, content releases, incidents, and accepted exceptions. | Each event has a date, affected scope, and accountable owner. |
| Output | Regression register | One row per finding with baseline, current value, delta, affected URLs or templates, severity, evidence, and suspected cause. | A second reviewer can reproduce every finding. |
| Output | Prioritized action list | Ranked actions with owner, due date, effort, dependency, acceptance test, and rollback or escalation condition. | Every P0–P2 item is accepted by an owner before review closes. |
| Output | Updated baseline | Approved changes to thresholds, cohorts, page specifications, and known exceptions. | Changes are versioned and never overwrite the evidence used for comparison. |
| Output | Review record | Scope, sampling method, decisions, deferred items, next check date, and annotations. | The next review starts from this record without reconstructing the quarter. |
The action list is the contract with the next work cycle. A slide deck without named actions is not an output.
Ready to Monitor Your AI Visibility?
Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.
The checklist
Monthly regression screen
1. Freeze the comparison and reconcile releases
What: Define the current complete month, the previous comparable month, priority cohorts, and every material release between them. Why: partial periods and unrecorded deployments turn normal variation into false alarms. How: use identical property, country, device, directory, and page-type filters; note seasonality; attach annotations to releases and incidents; and preserve exports before investigation changes the view. Tool: analytics, Search Console data, release log, and Annotation Outcomes. Done when: the review record states both windows, all filters, data completeness, known events, and the exact priority URL set.
2. Check indexation and discovery
What: Test whether intended canonical pages remain discoverable, indexable, and selected as expected. Indexation means a search engine has stored a page as eligible to appear; it is distinct from merely crawling the URL. Why: an accidental noindex, robots rule, wrong canonical, redirect, or sitemap change can remove otherwise good pages from search. How: compare the eligible inventory with sitemap counts, inspect every priority exception, sample each template, and separate “not checked” from “not indexed.” Tool: URL Inspection, Sitemaps and Indexing, crawler, server response checks, and the canonical inventory. Done when: every priority URL has the intended response, robots directive, canonical, and index verdict; count changes reconcile to approved releases; and every unexplained exclusion has an action owner.
3. Check Core Web Vitals and availability
What: Compare page and template performance against the signed baseline. Core Web Vitals are field measures of loading speed, responsiveness, and visual stability: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Why: shared scripts, media, consent tools, fonts, and templates can regress many pages without changing the copy. How: compare 75th-percentile field data by page type and device, check origin fallback labels, inspect the worst affected priority pages, and match timing to releases. Use lab tests only to diagnose, not to replace field evidence. Tool: Performance Impact, URL Inspection, browser performance tooling, uptime history, and release annotations. Done when: every priority cohort has a pass, explained unknown, or ticket; the failing metric and affected template are named; and the next field-data checkpoint is scheduled after a fix.
4. Validate schema and rendered meaning
What: Test required structured data —standardized machine-readable markup—on priority pages and changed templates. Why: one invalid template field can remove rich-result eligibility or misstate the page’s entity across thousands of URLs. How: inspect detected schema nodes, errors, and warnings; compare rendered markup with visible content and the approved page specification; and sample both populated and edge-case records. Tool: URL Inspection rich-results verdict, schema validator, rendered HTML, and template specification. Done when: required types are present, zero blocking errors remain on priority or newly changed templates, facts match visible content, and warnings are accepted or assigned.
5. Find broken internal routes
What: Detect internal links, images, scripts, canonicals, and redirects that no longer reach their intended destination. Why: broken routes stop users and crawlers, while chains waste time and conceal weak maintenance. How: crawl priority sections and all URLs changed during the month; classify 4xx, 5xx, loops, chains, and malformed destinations; confirm a representative failure manually; and trace repeated faults to their component or content source. Tool: crawler, HTTP checker, sitemap, CMS link source, and route map. Done when: zero broken links remain in primary navigation or conversion paths, all repeated template-level faults have one root-cause ticket, and isolated content faults have exact source pages and destinations.
6. Review freshness distribution
What: Compare the age and update distribution of pages against declared review dates and business risk. Freshness is the continued accuracy and usefulness of content, not the act of changing a timestamp. Why: a sitewide average hides a directory of expired pricing, product steps, regulations, or claims. How: segment pages by type, owner, last material update, next review date, and risk; inspect unexpected sitemap additions or removals; and sample overdue pages for factual change. Tool: Content Freshness, content inventory, sitemap history, and subject-matter owners. Done when: every overdue high-risk page is corrected, retired, or scheduled; anomalous sitemap churn is reconciled; and no update is counted from lastmod alone.
7. Check page-specification conformance
What: Verify that pages still follow their approved post-type and element rules for title, direct answer, headings, evidence, author or reviewer information, links, calls to action, and required metadata. Why: editors and template changes create gradual variation that weakens consistency even when individual pages look acceptable. How: sample every active page type, include the newest and highest-value pages, compare each page with a versioned specification, and record each failed field rather than one subjective quality score. Tool: specification library, rendered page, content inventory, CMS export, and AI Accessibility where heading or accessibility structure is relevant. Done when: the sample and method are recorded, every required field is pass/fail/not-applicable, systemic failures have a template or workflow owner, and isolated failures enter the content queue.
8. Convert findings into an action list
What: Replace observations with a ranked remediation queue. Why: a report nobody owns preserves evidence of failure but does not reduce risk. How: deduplicate symptoms into root causes; score severity, reach, confidence, and effort; make the smallest action that fixes the cause; and specify verification before assigning it. Use priority P0 for active loss or unsafe states, P1 for material high-confidence regressions, P2 for bounded deterioration, and P3 for monitored improvements. Tool: regression register, ticket system, inventory, release calendar, and Annotation Outcomes. Done when: each material finding has one action, one owner, one due date, one acceptance test, and one evidence link; accepted exceptions have an expiry date; and owners have acknowledged P0–P2 work.
Quarterly depth review
9. Expand the sample and look for structural drift
What: Repeat the six checks across all page types, directories, markets, devices, and risk bands, including low-traffic pages that monthly priority sampling may miss. Why: small repeated errors and neglected cohorts can remain below monthly alert thresholds while accumulating into systemic weakness. How: use stratified sampling—separate samples for each page type and risk band—then compare failure rates with the previous quarter. Crawl the full eligible inventory where site size and tooling allow; otherwise document the sampling confidence and exclusions. Tool: crawler, inventory, URL Inspection sample, Performance Impact, Content Freshness, validators, and specification scorecards. Done when: every active template and material directory is represented, exclusions are explicit, systemic patterns are separated from isolated rows, and the regression register includes quarter-over-quarter movement.
10. Recalibrate baselines, ownership, and controls
What: Decide whether targets, priority cohorts, review dates, page specifications, monitors, and owners still match the business. Why: a baseline can become obsolete after a redesign, product change, market launch, or portfolio cleanup; treating it as permanent creates false alerts and blind spots. How: compare actual healthy behavior with current goals, add new critical journeys and templates, retire deleted cohorts, test alert routing, review every exception, and require evidence for threshold changes. Tool: baseline pack, inventory, business roadmap, incident history, monitoring configuration, and stakeholder review. Done when: the next quarter has a signed baseline, complete owner map, tested notification path, dated exceptions, and a change log that preserves the previous values.
Tools in AmICited
AmICited provides inspection, trend, and annotation evidence. A sampled product report does not replace a full crawl, and an unknown value never counts as a pass.
| Product view | Use in the health check | Deep link | Evidence to retain |
|---|---|---|---|
| URL Inspection | Check index verdict, Google-selected canonical, mobile usability, Core Web Vitals, and schema nodes for priority or sampled URLs. | Open URL Inspection | URL, inspection time, verdicts, canonical comparison, last crawl, data coverage, and ticket. |
| Performance Impact | Rank affected pages by LCP, INP, CLS, FCP, TTFB, and technical health, then refresh after remediation. | Open Performance Impact | Page, device or cohort, metric, percentile, source window, baseline, and release annotation. |
| Sitemaps and Indexing | Reconcile submitted sitemap counts, warnings, errors, and last download; request recrawling only after a fix passes. | Open Sitemaps and Indexing | Sitemap URL, submitted URLs, download time, warnings, errors, and action receipt. |
| Content Freshness | Inspect age distribution, update cadence, sitemap churn, directory risk, and lastmod coverage. | Open Content Freshness | Host, directory, window, age band, URL changes, coverage confidence, and review decision. |
| AI Accessibility | Check heading and accessibility structure, sitemap coverage, crawler permissions, and real agent reachability as separate facts. | Open AI Accessibility | Check name, score or state, exact failure, fetch evidence, affected template, and owner. |
| Annotation Outcomes | Connect releases and fixes to expected checkpoints without claiming that timing proves causation. | Open Annotation Outcomes | Annotation, scope, expectation, baseline, checkpoint, verdict, override, and caveats. |
Stay Updated on AI Visibility Trends
Get the latest insights on AI mentions, brand monitoring, and optimization strategies.
Decision rules
These are operational defaults, not universal ranking guarantees. Replace them only with a versioned site-specific baseline. “Bad” means investigate or act; it does not by itself prove the cause.
| Watchlist signal | Bad looks like | Required decision |
|---|---|---|
| Indexation | Any priority URL becomes blocked, non-canonical, redirected unexpectedly, or not indexed; or eligible indexed count falls by both 5% and 25 URLs without an approved removal. | P0 for a broad active block; otherwise inspect the cohort within one working day and reconcile every changed URL. |
| Sitemap integrity | Any submitted priority URL returns non-200, is non-canonical, or is blocked; warnings or errors increase from zero; submitted count differs from the eligible inventory by more than 1%. | Fix the generator or inventory before resubmission. Do not use repeated indexing requests as a remedy. |
| LCP | 75th-percentile LCP exceeds 2.5 seconds; poor at more than 4 seconds. | P1 when a priority template enters poor or worsens by at least 500 ms; diagnose the shared cause. |
| INP | 75th-percentile INP exceeds 200 ms; poor at more than 500 ms. | P1 for a priority journey in poor; otherwise assign the component causing long interaction delay. |
| CLS | 75th-percentile CLS exceeds 0.10; poor above 0.25. | P1 for poor priority pages or a template-wide shift; preserve element-level evidence. |
| Schema validity | Any required type disappears, any blocking error appears on a priority or changed template, or markup contradicts visible content. | Correct the template or record an explicit eligibility decision; warnings require review, not automatic failure. |
| Broken routes | Any failure in primary navigation, checkout, lead, login, or documentation path; any loop; any 5xx; or more than 1% broken internal destinations in the crawl. | P0 for blocked primary journeys or widespread server failure; P1 for template faults; repair isolated links in the next content batch. |
| Freshness | Any high-risk page passes its review date; more than 10% of a risk cohort is overdue; or daily sitemap additions/removals exceed twice the trailing 30-day median without a release. | Validate facts and crawl state. A timestamp change alone does not clear the finding. |
| Specification conformance | Any mandatory legal, pricing, author, canonical, or primary-answer field is missing on a priority page; or fewer than 95% of sampled pages pass all mandatory fields. | Stop affected publishing for a systemic workflow fault; correct isolated pages and retest the sample. |
| Action ownership | Any P0–P2 action lacks an owner, due date, or done-when test when the review closes. | The SEO lead escalates before publishing the review record; an unowned item is an incomplete health check. |
Prioritize with a transparent score, not intuition alone. Rate severity, reach, and confidence from 1–5, multiply them, then divide by effort from 1–5. The score orders work within a priority class; it never pushes an active P0 below a cosmetic quick win. Add dependencies and business deadlines after scoring, preserve the inputs, and let the accountable owner override the order only with a written reason.
Deliverable
Hand over one versioned health-check pack, not a presentation detached from its evidence. A spreadsheet, database, or ticket board is suitable if it contains four connected views:
- Review cover: date, monthly or quarterly scope, owner, comparison windows, data limitations, releases, sample method, and sign-off.
- Regression watchlist: baseline, current value, delta, threshold, affected cohort, evidence link, status, and whether the finding is new, persistent, resolved, or accepted.
- Prioritized actions: priority, root cause, action, severity, reach, confidence, effort, dependency, owner, due date, acceptance test, rollback or escalation condition, and verification evidence.
- Baseline change log: old value, new value, reason, approver, effective date, exception expiry, and next review date.
The review closes only when P0–P2 owners accept their work, informational findings are separated from actions, and the next check is scheduled. Completion means “the operating system knows what happens next,” not “the meeting occurred.”
What goes wrong
The dashboard becomes the agenda. The team clicks through reports but never states the baseline, threshold, or affected URLs. Discussion feels thorough while no reproducible finding exists.
Monthly review expands into a full audit. Reviewers inspect everything manually, miss the timebox, and stop running the check. Keep monthly work sensitive and narrow; move deep sampling and control design to the quarter.
Quarterly review repeats the monthly slides. Slow drift in low-traffic templates, ownership, exceptions, and specifications remains invisible. The quarter must widen coverage and challenge the baseline.
Unknown is colored green. Low-traffic Web Vitals, an unchecked URL, or incomplete freshness history is treated as healthy. Unknowns need a direct test, coverage action, or later checkpoint.
Every symptom becomes a ticket. Fifty broken links from one template produce fifty tasks, hiding the shared cause and wasting ownership. Deduplicate at the component, template, route, or workflow level while retaining affected URLs as evidence.
Percent changes dominate tiny denominators. One excluded page becoming two is reported as a 100% increase. Pair relative thresholds with absolute counts and priority cohorts.
Freshness means touching timestamps. Editors update lastmod without improving a fact, instruction, offer, or decision. Review dates and material change evidence are the control, not the timestamp alone.
Thresholds are changed to make the report green. A regression becomes the new baseline without remediation or approval. Preserve historical values and require a reason, owner, and effective date for every recalibration.
The action list has no verification. “Fix schema” or “improve speed” cannot be closed consistently. Each task must name the affected scope, target value, evidence source, and post-release check.
Next phase
The next step is the appropriate remediation queue inside continuous refresh and iteration . Technical blockers go to engineering with the failing cohort and reproduction; page-level decay goes through the content refresh checklist ; new or substantially changed pages pass the pre-publish SEO checklist before release.
The receiving owner needs the baseline and current measurement, affected URL or template set, suspected root cause, priority score, dependency, due date, and done-when test. After release, annotate the intervention and schedule the evidence checkpoint. Feed the verified outcome into the next monthly review and use repeated findings to change the template, specification, or publishing control rather than repairing the same symptom forever.
Frequently asked questions
The FAQ above defines the cadence, timebox, ticket threshold, prioritization method, and treatment of missing data. Use the monthly check to catch change quickly, the quarterly review to challenge the system, and the action register to make sure evidence becomes work.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card