In short: Everything the audit modules ask you to check by hand can be checked by the build instead, and on a custom stack there is no reason it should not be.
Four of them are worth the afternoon: the answer is in the response, no page is accidentally noindexed, the sitemap holds what you think it holds, and no claim lost its source.
A check that runs on every deploy is the difference between finding a regression in a minute and finding it in a quarterly measurement, where it will be confused with something else entirely.
Why This Is Worth Automating
The failures in this course are quiet. A robots rule, a noindex left on after a rebuild, an answer that moved below three other blocks: none of them breaks a page, so nothing complains and nobody notices until the measurement comes back flat.
That is exactly the profile of a thing to put in the build, and it is the same argument as any other test. You are not automating because the check is hard. You are automating because the failure is silent.
The Four Worth Writing
The answer is in the response. For a named list of important routes, build the page and assert that a known sentence appears in the output. This is the one that catches a rendering change nobody connected to content.
Nothing is noindexed by accident. Assert that no route in that list emits a noindex, and that the ones which should are the ones that do. A rebuild or a copied template is how the wrong page acquires one.
The sitemap holds what you expect. Assert a count and assert that the important routes are present. A sitemap that silently halves is a discovery failure with no other symptom.
Numbers still have sources. If your content carries figures, assert that a number in a published page has a link or a date near it. This one is a judgement call in a way the others are not, and it still catches the paragraph somebody edited down.
Assert against the built output, not the source. The whole point is that the transformation between what you wrote and what is served is where these failures live. A test that reads your markdown proves your markdown is fine.
What Not To Put In The Build
Anything that calls an assistant.
Answers vary between identical runs, so a test asserting that a model names you will fail intermittently for reasons unconnected to your code, and an intermittently failing test is a test that gets disabled. Measurement belongs on its own schedule, against a noise floor, which is the subject of Measuring Your Own Noise Floor.
The same goes for anything requiring a network call to a third party. A build that fails because somebody else had an outage teaches a team to ignore the build.
A Guard Is Worth More Than A Report
The difference between a check that prints a warning and one that fails a build is whether anybody acts on it.
Make these fail. A deploy that would remove twelve pages from the sitemap should not complete because somebody was going to read a log. The one exception is a check whose failure is ambiguous, and for those the honest thing is to say so in the output rather than to fail on a guess.
This site does it, and the guard had this exact fault. A check here confirms no exam question has leaked into the public bank. It reads prompts with a pattern that only matched one style of quotation mark, so a question written the other way passed through without being examined, and the check reported success. It now counts what it extracted against how many questions exist and fails when those disagree, which is how the gap was found. A guard that cannot fail is decoration.
Key Takeaways
- These failures are silent, which is the argument for automating them rather than the checks being difficult.
- Four are worth writing: the answer is in the response, nothing is wrongly noindexed, the sitemap is intact, and numbers kept their sources.
- Assert against the built output, because the transformation is where the failures live.
- Keep anything that calls an assistant out of the build. Varying answers make an intermittent test, and an intermittent test gets disabled.
- Make them fail the build rather than print a warning, and make sure each one can actually fail.
Check yourself
Before you move on
Not scored, not recorded, and not part of the certificate. Both answers are settled by a sentence in this lesson, and the reasoning appears whichever option you pick.
- 01
What is the argument for putting these checks in the build?
- 02
Why should a check that asks an assistant whether it names you stay out of the build?