Ali Demir

What I check before shipping a site

A working checklist, refined over several launches, for the things that are cheap to verify now and expensive to discover later.

635 words3 min read

Every item here exists because I once skipped it and paid for it. The list is ordered by how much it costs to find the problem after launch rather than before.

Content reaches the reader

  • View source on the deployed page, not the local one. If the article text is not in the raw HTML, no crawler that matters will see it.
  • Disable JavaScript entirely and reload. Whatever remains is what most machine readers get.
  • Fetch a page with curl and read the output. Browsers repair broken markup silently; curl does not flatter you.
  • Confirm the canonical URL is absolute, correct, and points at the version you actually want indexed.
  • Check that a page with no content — an empty category, a tag with one post — still renders something coherent rather than an empty shell.

Structure holds up

  • Read the heading outline on its own. It should be a fair summary of the page. If it is not, the headings are decoration.
  • Verify there are no skipped heading levels. An h2 followed by an h4 is a claim about structure that is not true.
  • Confirm exactly one h1 per page, and that it says what the page is rather than what the site is.
  • Check that every link's text makes sense read in isolation. "Read more" appears in an index of links with no context around it.
  • Make sure the language attribute on html is set and correct. It is one attribute and it changes how the page is pronounced, hyphenated, and translated.

The machine-facing files exist and are right

  • Load /robots.txt and read it aloud. Misplaced Disallow lines are the single most expensive typo available on the web.
  • Load the sitemap and count the URLs. If the number is wrong, something is being excluded silently.
  • Fetch the RSS feed and put it through a validator. Feeds fail quietly and nobody reports it.
  • Check that drafts are absent from all three. It is easy to exclude a draft from the page listing and forget the feed.

Typography survives contact with reality

  • Read a long post on a phone, outdoors, at whatever brightness you actually use. Contrast decisions made on a calibrated monitor in a dim room do not survive this.
  • Resize the window to the narrowest and widest plausible sizes and watch the measure. Lines longer than about seventy-five characters stop being readable, and nothing warns you.
  • Print a page, or at least open the print preview. Print stylesheets are almost always broken, because almost nobody looks.
  • Check the page in both colour schemes, including the moment of switching. A theme that only works in one direction is a theme that was tested once.
  • Look at a paragraph of text with the fonts blocked. If the layout collapses without the webfont, it will collapse for the first paint too.

Nothing is quietly broken

  • Click every link in the navigation and footer. This takes two minutes and catches the embarrassing ones.
  • Load the site with a cold cache on a throttled connection and time it honestly.
  • Check the 404 page exists, is styled, and offers a way back.
  • Confirm the favicon actually resolves. A missing one produces a 404 on every single page load.
  • Search for your own domain in the output of a full crawl for stray localhost or staging URLs.

The list is not exhaustive and it is not meant to be. It is the set of checks whose cost is under a minute each and whose failure is measured in weeks of quiet damage. Anything that stops meeting that ratio comes off the list, and anything that starts meeting it goes on.