Before anyone writes a single automated test, a public page has already told you a lot: what it answers over https, which links it exposes, whether its fields have labels, which headers it sends, how long the document takes to arrive.
Most first test plans stop at "the happy path works". Here is the list I use instead when I read a page for the first time. Each kind has one example case, written the way I would hand it to a team.
-
Functional (
FN-01): The reviewed URL answers over https -
Content (
CT-01): The meta description is present and short enough to read -
Links (
LK-01): Same-host links discovered from the start page resolve -
Forms (
FM-01): Visible fields have labels -
Accessibility (
A11Y-01): Images expose a text alternative -
Security (
SEC-01): HTTPS is the only way in -
Privacy (
PR-01): A privacy notice is linked from the page -
SEO (
SEO-01): Title, description, canonical, and social tags agree -
GEO (
GEO-01): AI answer and search crawlers may read the site -
Performance (
PF-01): The HTML document arrives inside a stated budget -
Load (
LD-01): An authorised baseline could repeat the document fetch -
Mobile (
MB-01): The layout holds at a phone width -
Internationalization (
I18N-01): The lang attribute matches the copy a person reads -
Resilience (
RS-01): A missing path returns a deliberate not-found page -
Compatibility (
CMP-01): The page still explains itself when scripts do not run -
Media (
MED-01): Video exposes captions or a transcript path -
Analytics (
AN-01): Analytics tags wait for a recorded choice when the page asks for consent -
Commerce (
CM-01): A catalog or payment marker is covered without placing an order -
Visual (
VIS-01): Images reserve their box before they paint -
Platform (
PLAT-01): The public Salesforce path stays available without an org login -
API (
API-01): A public API description is listed without calling the API
How to use the list
- Read the public response first: status, headers, the HTML that arrives before any script runs.
- Follow the same-host links you can see, a couple of levels deep, and note what each one answers.
- Keep only the kinds you will actually run. A list nobody runs is worse than a short one.
- Name the tool for each case (Playwright, Cypress, Robot, Selenium, WebdriverIO, Appium, JMeter, Gatling, axe-core, Lighthouse, k6) so the case is ready to become code.
- Treat security headers as signals, not proof. A missing header is a question for the owner, not a finding of a break-in.
What this list is not
It is not a certification and not a penetration test. Reading a public page does not sign in, submit forms, or generate load, so anything behind a login or under real traffic still needs its own plan.
This article was created with the help of AI and checked for accuracy before publishing.
Top comments (2)
The "Visual: images reserve their box before they paint" check is easy to turn into a concrete test: every img in the HTML should have width and height attributes (or an aspect-ratio in CSS), which you can read without running any script. It catches layout shift at the source.
One suggestion for the list: a "Keyboard" case, for example that the first Tab stop on the page is a skip link or the main navigation, and that the focus outline is visible. Accessibility checks that look only at HTML miss that, and it's quick to add.
Thanks, Kai. Reading width and height straight from the HTML is a nice way to make that check concrete. Keyboard is a good addition too: the first Tab stop and a visible focus outline are exactly what an HTML-only check can't see.