A site isn't done just because it opens in a browser. This post covers the checks run while the first version of the site you're reading was being prepared for launch: what was checked, how it was measured, and which problems it caught. There are seven parts.
1. At every screen width
Each of the six pages was opened at three widths: 360 pixels (a small phone), 768 (a tablet), and 1280 (a desktop). This wasn't done by eye; the pages were loaded in a headless browser and measured for anything spilling out sideways. Result: no horizontal overflow.
Problem caught: the 27-character email address broke mid-word at 360 pixels. A shorter address solves it; if it stays long, the note says to reduce the font size.
2. Can everyone read it?
- Every image has alt text describing what it shows. Purely decorative graphics are hidden from screen readers.
- Contrast between text and background was calculated one by one; the lowest ratio is 5:1.
- The pages were navigated with the keyboard alone, using Tab. The order makes sense: "Skip to content" first, then the logo, the main button, and the menu. The focused element has a visible outline.
Problem caught: inside a light band, the dark case study card's title and "Read the case study" button were invisible. The band's color rule was overriding the card's colors. It was fixed and written into the site's notes as a warning so it doesn't happen again.
3. Does it load fast?
- The pages make no requests to other servers; the fonts are part of the site too.
- The stylesheet is 41 KB.
- Screenshots are served as WebP in different sizes for different screens; the largest is 41 KB.
4. Search basics
- One main heading (h1) per page.
- Page titles are between 25 and 45 characters, descriptions between 34 and 143.
- Canonical addresses, social sharing tags, a sitemap, and robots.txt are all in place.
5. No broken links
Every internal link and every image path was checked to make sure it points to a file that actually exists in the built site.
6. No browser errors
The pages were loaded 18 times with the browser console open. No errors or warnings, and no failed requests.
7. It's written down
The results and every problem caught were recorded in the site's own log. If something needs to change months from now, the answer to "why was it like this?" is there.
One trap: full-page screenshots
During the checks, a gallery showed up empty. It wasn't a bug in the site: the images load as they come close to the screen, and the full-page screenshot was taken without scrolling. You have to scroll first and then capture. Otherwise you end up trying to fix a problem that isn't there.
What this list doesn't tell you
Passing these checks doesn't mean the site is good. It means these particular mistakes aren't there. Whether the site is good is up to the people who visit it. But an overflowing menu, an invisible button, or a broken link can settle that question before they read a word. That's why the checks happen before launch.
Working on something similar? Get in touch on the contact page.