SEO tests

SEO tests audit pages against a configurable list of SEO and content checks. They are best run on a schedule against pages you do not want quietly drifting out of best-practice, including your homepage, your top landing pages, your category pages, and any URLs that drive significant organic traffic. Unlike functional tests, SEO tests rarely fail in dramatic ways. They fail by accumulating small regressions, which is exactly what scheduled monitoring catches and one-off audits miss.

1234

1. 1Run limits: how many pages are crawled and how much history is kept.
2. 2The target: a page, a domain, or a sitemap.
3. 3Toggle the checks this test should run on every page.
4. 4Thresholds tune the length and count checks to your house style.

Choosing pages and checks

In the SEO builder you list the pages to audit and enable the checks you care about. The current checks cover status code, title tag, meta description, canonical, robots meta, Open Graph, Twitter card, hreflang, H1 count, viewport, structured data, redirect chains, image alt coverage, robots.txt, sitemap availability, and optional content-change detection. Each check is independently toggleable, so you can audit exactly what matters to your team and ignore the rest.

Tuning thresholds

Some of those checks have thresholds you can tune to match your house style. The defaults are sensible (60-character titles, 160-character descriptions, one H1 per page, 100% alt-text coverage, and a five-hop redirect limit) but you can relax or tighten them per test. For example, if your CMS reliably produces 70-character titles and you have decided that is acceptable, raise the threshold so the check stops complaining about something you have already accepted as policy.

JavaScript-rendered pages

For pages rendered client-side, enable "Render JS" so Testsnag waits for JavaScript to execute before reading the DOM. This is essential for single-page applications, since otherwise the audit will see an almost-empty HTML shell and report missing content that is in fact present after hydration. The trade-off is a slightly slower run, which is rarely a problem on a daily or weekly schedule.

Reading the results

The result is a per-page breakdown of what passed, what failed, and what changed since the last run. With "Fail on Content Change" enabled, the test will flag unexpected edits to page content as well as failed checks. That is a useful safety net for catching CMS changes that slipped through review, accidental copy edits, or pages that were rewritten without anyone noticing until it was too late.