Put the Design in Front of a Browser and See What Comes Back
Every design in the catalog is checked before it ships, and the check is deliberately the crude one: put it in front of a real browser, with a real account behind it, and see whether a complete page comes back.
Why a status code is not enough
The obvious test is to fetch the page and look for a 200 response. It is also close to worthless on its own, because a 200 only says the server answered. It says nothing about what it answered with.
A page can return 200 and be a fragment that stops halfway through. It can return 200 and be missing every image. It can return 200, weigh half a megabyte, and consist mostly of a script that failed before drawing anything. Every one of those is a broken page and every one of them passes a status check.
So the check reads what actually came back: does the document finish, does the markup close, did the page draw, are the assets it names really there.
What reading the rendered page catches
Things that are invisible in the source. Placeholder text that only appears once the page has assembled itself is a good example, and that is how the content covered in your own words on every design gets verified.
The general principle is worth borrowing for your own site: check the thing a visitor receives, not the thing you think you published. Those are different objects and only one of them matters.
The limits of any check
A check answers the question it was written to ask, and is silent on everything else. A suite that verifies pages return, assets load and markup is valid can be entirely green while something it was never asked about is wrong.
That is not an argument against checks. It is an argument for adding a new question whenever you find one worth asking, and for looking at pages by hand periodically even when everything is passing.
Related: link monitoring across your site, which is the same idea applied continuously rather than before release, and faster page loads.
Browse the catalog or create a free actor website.
