Tutorials · site checks
Automate repetitive site checks with simple scripts
A small, dependable checking loop for links, required files, page metadata and a build that can be repeated on any machine.
The useful version of a web practice is the one that can be repeated by someone else. This note keeps the scope tight, names the trade-offs and ends with a way to check the result. Continue with the site checks index or meet the Sites To Use editorial desk behind the notes.
List the checks a person repeats
Automation begins with a visible routine. Write down what you already inspect by hand: the build exit code, required service files, internal links, image paths and a few page-level promises. Keep the list narrow enough that a failure points to a next action.
A check should answer one question. When several unrelated assumptions hide behind one green result, the signal becomes difficult to trust.
Make failure readable
Return a non-zero exit code when a required condition fails, and print the file or URL beside the reason. Stable ordering matters too: deterministic output makes a later comparison useful and avoids hiding a new error in a reshuffled report.
Keep a small JSON report for machines and a human-readable summary for review. Both should come from the same findings.
Run it at the boundary
The most useful place for a site check is just after the build and before a handoff. Run the same command locally and in continuous integration, with the same inputs. If an exception is intentional, document it in the inventory rather than weakening the general rule.
Turn the publishing contract into fixtures
Start with a small known-good site and a set of deliberate failures. Include a missing image, broken internal link, duplicate canonical, invalid worker, absent sitemap entry and page that is too short. Each rule should identify the exact file or URL and return a stable code. These fixtures prove that a checker can detect the defect it claims to cover, not merely that it can produce a green report on the current build.
Separate local deterministic checks from network checks. File existence, metadata, internal links and generated inventories can run quickly after every build. Live status, TLS, headers and redirect chains belong in a later stage with explicit timeouts and retries. Save both a structured report and a short review summary. Stable ordering and reproducible inputs make it possible to compare releases without mistaking shuffled output for new risk.
Choose automation tools by failure quality
Evaluate a checker on the defects your publication actually fears. Confirm that it can run locally and in continuous integration, return a non-zero exit status, emit JSON or SARIF, exclude documented cases without silencing a rule globally, and show enough evidence to reproduce a failure. GitHub Actions interprets a non-zero action exit code as failure, while Node also exposes an explicit process exit code for scripts that need to finish cleanly before reporting failure. Human help deserves the same standard as a script: when a publication brings in an SEO consultant, the useful question is whether their claims fail loudly under a check you can run yourself. That is the whole idea behind our vetting routine for outside SEO help, which starts with a query typed into Google.
For a commercial service, test private-route support, crawling limits, concurrency, retention, webhooks, exports, user roles and renewal pricing. Check whether results remain available after cancellation and whether the same rule set can be run outside the vendor. Keep W3C validators or another independent checker in the loop for standards-focused evidence. A dashboard is useful only when its findings can be traced to a page, repeated and fixed.
Sources and further checks
These primary and official references define the standards or product behaviour used in this field note. Accessed August 25, 2026.
