This is a very boring list, but it is necessary to have a check-list; and this seems the simplest solution. At work previously I have changed serverside language 3times in 2months, and my tooling in each case is different, with different levels of maturity. This document will age; so if you read this after Jan 2023, pls check the last update value. I have a domestic document from 2013, but that is too old.

A website that is accessible from the internet should have:

  • Artifact: 'contact-us'. Yes this ties up staff, but selling without communication isn't a viable process.
  • Artifact: To comply to bits of legislation, the site should declare & manage cookie usage. Nearly all of these that I have seen are a third party tool.
  • Artifact: a sensible domain. Whether its best to use a “new TLD” domain, or a more traditional '.com' will vary with your product offering, and who your clients are.
  • Artifact: terms & conditions (for anything commercial).
  • Artifact: a sitemap, for search-engines, and less traditional users (e.g. blind people).
  • Artifact: consider if logins are actually needed. no login= no data stored = simple life. Marketing people want everyone to identify themselves at every step so they are easier to sell to. If logins are needed, consider outsourcing the process; it's not a USP or significant user-journey for nearly every business.
  • Artifact: If the site is a sales platform / landing->lead funnel, add standard SEO features (I don't normally make these)
  • Tech: HTTPS access, and headers to force HTTPS, [1] and also see HSTS below
  • Tech: a HTTP 404 handler [2]
  • Tech: a HTTP 5* handler [2]
  • Tech: a robots.txt 1 2
    • Recommend blocking search engine access to any URLs which are not content centric (e.g. contact-me)
    • supported browsers: approximately all .
  • Tech: a Content-Security-Policy header 3 4
    • supported browsers: 98.33% nearly all 5 outliers in footer [4]
  • Tech: a HSTS 6 header.
    • supported browsers: 98.25% nearly all 7 outliers in footer [4]
  • Tech: a Content type options header.
    • supported browsers: 93.21% nearly all 8 Absent from opera and minority browsers.
  • Tech: a Clear-Site-Data header
    • supported browsers: 75.81% most users, noticeably not any version of Safari or MSIE 9
  • Tech: CORs headers are abit big for a bullet point; I made an article as people kept asking what they were.
    • supported browsers: 98.63% nearly all 10 Absence is mostly opera mini
  • Tech: HTTP2 and to upgrade to HTTP2.
    • supported browsers: 97.13% nearly all, outliers are [4]
  • Tech: Asset compression [3], the process of making all the files as small as possible, so they will download faster. Very important when 2g and 3g was how “fashionable sales people” used the internet.
    • supported browsers: all, compressed assets follow the same rules as non-compressed ones
  • Tech: Cache-Control 11 and Expires 12
    • supported browsers: assume all, not listed in
  • Tech: for branding, a favicon.XXX image; note there are a range of formats that can be supported. Pls see favicon-notes
    • supported browsers: A standard setup is 3-4 file formats, supplying a very good coverage. Single file formats have something like 80% 13
  • Tech: relevant flavours of rich snippets/ meta data, to improve accessibility to your data by both users and search engines. Again this is too big for a bullet point, see webpage-micro-data
    • supported browsers: broad as this is a decade old technology, see link for more details.
  • Tech: Analytics, if it inside your user-cases. When websites are sales pipelines, this is essential. I previously wrote current-gA - 2018 or for in-house analytics analytics-2
    • supported browsers: all
  • Tech: asset headers (like MIME for JS with UTF8)
    • support varies, but very good in aggregate.
  • Tech admin: Analysis of logging, so any errors can be resolved promptly. If you are using a website as an active communication channel with your users; this is essential.

Lists of other headers 14 15 16

Footer notes
Note there are golang HTTP middleware frameworks which ship without 404 or 500 support “for free”.

  1. [1] Specific notes to force HTTPS depend on what server software you are using. Use a search engine.
  2. [2] Linking to Wiki, as each different framework would be a different article to read. As far as this is a problem spec not a solution, I think this is the least stupid option for anyone who doesn't know what these errors mean.
  3. [3] Again specific notes depend on your technology. A popular search term is “minify”. There are a large number of tools to support this process.
  4. [4] The outliers are consistently old MSIE, which no-one should ever use for a very long list of problems; and opera mini, as the feature contradicts the major objectives of this niche browser.

Some similar articles in worklog