Website Quality Standards and Guidelines

The following represent my quality standards. I use this as a checklist for evaluating existing websites, but also a checklist to build websites according to.

This standard is often criticized as overly strict. I would prefer to aim for excellence and fall short than to aim for mediocrity and succeed. Additionally, these are guidelines, not hard-set, unbreakable rules.

These guidelines are a living document and change over time. I welcome feedback and aim to be better every day. If you spot a mistake or omission - please contact me using the information at the bottom of this page.

Sitewide

Items that impact the entire website.

Security

I strongly advise layered redundant website security.

  • Always password protect development or test websites or pages
    • Password protect development websites at the directory level by setting permissions (typically done via cPanel or .htaccess)
  • SSL certificate (TLS 1.3 preferred) and use of HTTPS
    • A padlock over HTTPS
  • Server signature off
  • Block Libwww-perl access
  • Contact information matches WhoIs records
  • Use of a .env file for credentials
  • Never use "admin" as a username
    • Never display usernames publicly (use an alias if displayed)
  • Maintain recent website backups and store them in 3 unique places
  • Disable iframe
  • Security headers
    • Content Security Policy
    • HSTS
    • X-Frame-Options (or frame-ancestors in CSP)
    • X-Content-Type-Options
    • Referrer-Policy
    • Permissions-Policy

Industry Specific Security

For any industry requiring advanced security protocols, adhere strictly to the highest applicable compliance frameworks (e.g., HIPAA, PCI-DSS, GDPR).

Example Industry: Healthcare & Medical Standards (HIPAA)

  • Zero-Transmission Tracking: Absolute ban on tracking pixels, beacons, and third-party analytics scripts (e.g., Google Analytics, Meta Pixel) that leak user IP addresses alongside medical page context.
  • Zero-Cookie Baseline: Only strictly necessary, non-identifying functional cookies are permitted.
  • Total Form Isolation: Patient intake or contact forms must be completely hosted and executed on a third-party, HIPAA-compliant form engine. The developer must be structurally excluded from accessing form submission data or admin inboxes.
  • Client Communications Warranty: The client must provide written confirmation that all email addresses and telephone numbers listed on the website route exclusively to infrastructure protected by an active Business Associate Agreement (BAA).
  • Server Log Masking: Server-level configuration must obfuscate or disable the retention of visitor IP addresses in connection with specific medical URL paths.
  • Developer Liability Boundary: The developer will under no circumstances sign a BAA. The developer must never be granted access to Protected Health Information (PHI). All Personally Identifiable Information (PII) on medical sites shall be treated as assumed PHI, and its storage on developer-managed systems is strictly prohibited.

WordPress Security Specifics

  • Postfix WordPress Salt
  • Remove the WordPress generator
  • Add a captcha to login page (e.g Google reCAPTCHA or Cloudflare Turnstile)
  • Move the login page (/wp-login.php no longer accessible, redirect to home)
  • Change the database prefix to anything other than wp_
  • Hide wp-config.php and .htaccess
  • Delete default files (readme.html, license.txt, and wp-config-sample.php)
  • Disable ability to edit files from the admin
  • Disable WP XML-RPC
  • Disable WP JSON and the REST API (or restrict if explicitly required)
  • Select plugins with care
    • Have a revenue source (i.e. freemium models) - preferably a paid version (i.e. not just a "buy me a coffee" link)
    • Download only from a trusted source (e.g. the original developer)
    • Review for vulnerabilities (e.g. via PatchStack's vulnerability database)
  • Custom themes are preferred (off the shelf themes are readily accessible, to explore for exploits)
  • Regular and disciplined update of plugins, WordPress core and theme (if applicable) recommended - but auto update is not recommended

Duplicate Content

  • Force the use of HTTPS (HSTS)
  • URL canonicalization
  • IP canonicalization
  • Remove file extensions (.html, .php etc)
  • Force the /index file to redirect to without /index (example.com/index.html resolves as example.com/)
  • Force a uniform trailing slash behavior (example.com/ to example.com/ or vice versa)

Required Pages and Required Files

Pages and files that are strongly recommended - i.e. "required".

Required Pages

  • HTML Sitemap (should automatically update for all content types: pages, posts, custom post types, etc)
  • Imprint (Impressum)
  • Policy Pages
    • Cookie Policy (Opt-out preferences)
    • Privacy Policy
    • Terms and Conditions
    • Website Accessibility Statement
      • Alternative means of service: email and phone
      • Hours of Operation (with time zone)
  • A "404, page not found" response
    • Including a search tool, a full HTML sitemap, a contact form and all contact information
    • Customer able to edit the 404 page content
  • Private, internal use pages

Required Files

  • llms.txt, llms-full.txt and .md files (as applicable)
  • robots.txt
    • with location of sitemap.xml
  • sitemap.xml (preferably with an index, should automatically update)
  • traffic-advice file in .well-known
  • favicon.ico in root
  • A complete touch icon/favicon suite loaded to root. Items with an asterisk* loaded in the head.
    • android-chrome-96x96.png
    • android-chrome-192x192.png
    • android-chrome-256x256.png
    • android-chrome-512x512.png
    • android-icon-36x36.png
    • android-icon-48x48.png
    • android-icon-72x72.png
    • android-icon-96x96.png
    • android-icon-144x144.png
    • android-icon-192x192.png
    • apple-icon-57x57.png
    • apple-icon-60x60.png
    • apple-icon-72x72.png
    • apple-icon-76x76.png
    • apple-icon-114x114.png
    • apple-icon-120x120.png
    • apple-icon-144x144.png
    • apple-icon-152x152.png
    • apple-icon-180x180.png
    • apple-icon-precomposed.png
    • apple-icon.png*
    • apple-touch-icon-120x120-precomposed.png
    • apple-touch-icon-120x120.png
    • apple-touch-icon-152-152-precomposed.png
    • apple-touch-icon-152-152.png
    • apple-touch-icon-precomposed.png
    • apple-touch-icon.png
    • browserconfig.xml
    • favicon-16x16.png
    • favicon-32x32.png
    • favicon-96x96.png
    • favicon.ico*
    • favicon.svg*
    • manifest.json
    • ms-icon-70x70.png
    • ms-icon-144x144.png
    • ms-icon-150x150.png
    • ms-icon-310x310.png
    • ms-tile-150x150.png
    • safari-pinned-tab.svg
    • site.webmanifest*
    • web-app-manifest-192x192.png
    • web-app-manifest-512x512.png
    • The set can and can prevent 404s (particularly on old domains) and can be achieved via https://realfavicongenerator.net and https://www.favicon-generator.org.

Speed

The 3 pillars of speed: few requests, a small page (packet) size, and caching. Core Web Vitals as a check on performance.

Requests

  • Enable keep alive
  • Less than 40 requests per page (the fewer the better – less than 10 for the simplest page - like a policy page)
    • A single CSS file and a single JS file are preferred, as applicable
    • Ideally, each file will be under 14.6KB
  • Prioritized requests (example: location of JS within the HTML document: head or body)
  • Select appropriate media types
    • Use of SVG (where applicable)
    • Use of font-based icons (where applicable)
    • Use of sprites (where applicable)

Page Size

  • Less than 1.5 MB (less than 1MB for the simplest page - like a policy page)
  • Enable Brotli, Gzip, or deflate (as applicable)
  • Minified HTML
  • Minified CSS
  • Minified JS
  • Vanilla code (strongly preferred)
  • No inline styles (those added via JS are acceptable but as only strictly needed)
  • Serve scaled images
  • Serve images via srcset as applicable
  • Serve optimized images (WebP/.webp images)
  • Use of SVG (where applicable)

Caching

  • Server-side caching
  • Client-side caching
  • Remove version from all URLs (?ver=)
  • Load all resources locally whenever possible (e.g fonts)

Core Web Vitals

  • Largest Contentful Paint (LCP) <2.5 seconds
  • Interaction to Next Paint (INP) <200 milliseconds
  • Cumulative Layout Shift (CLS) <0.1
  • First Contentful Paint (FCP) <1.8 seconds
  • Time to First Byte (TTFB) <800 milliseconds

Site Structure

  • Silo structure (use child, parent, grandparent, etc) and no empty/blank pages within the silo.
    • /about-us
    • /about-us/company-history
    • /about-us/our-team
    • /about-us/our-team/jane-smith
  • No underscore (_), & or ? in the URL (unless specifically required for functionality)
  • No numbered URLs (example.com/a-page-2)

Metadata

  • charset / UTF-8
  • Viewport
  • Author
  • Favicon and full touch icon suite
    • shortcut icon
    • icon (s)
    • apple-touch-icon (s)
    • manifest
    • msapplication-TileColor
    • msapplication-TileImage
    • theme-color Dynamic metadata:

Admin

  • Do not dramatically alter the admin UI/UX of an open source CMS, excepting simplification as applicable
  • Users of varying permission levels, as needed

3rd Party Tools

  • Implementation of Google Search Console
  • Implementation of Bing Webmaster Tools

Other WordPress Specific

  • Download WordPress core directly from WordPress (i.e. do not auto-install WordPress from a hosting company)
  • Never edit WordPress core (*note - hosting companies often install a modified version of WordPress core)
  • Never edit an off the shelf theme and always create a child theme (if using a purchased theme)
  • Structure themes according to standard WordPress hierarchy
  • Never edit a plugin
  • The fewer the plugins the better (typically only includes 6 plugins)
    • Security
    • Caching/compression/minification (varies by host)
    • "SEO"
    • 301 Redirects
    • Database maintenance/cleaning
    • SMTP
  • Autoload options under 200KB
  • Rename wp-content directory (as possible)

Per Page

Items that impact individual pages.

Page Structure

  • Exactly one h1 tag per page with text as the content (not an image)
  • h2 – h6 tags as necessary and properly structured/nested
  • No use of tables unless strictly needed/properly used and never for page structure (use of divs and display:table, display:table-cell; etc is permissible)
  • Use of ol, ul and dl only for lists and not for general structure or general repeating content
  • Proper use of header, footer, main, aside, section, hr and other document structuring elements. Not to be used to simply group blocks of code.

Page Content

  • HTML5 (XHTML is not acceptable)
  • Implementation of structured data
  • Sufficient text-to-code ratio (as a reasonable proxy for signal density)
    • Baseline, floor or minimum: 20% (functionality heavy pages)
    • Target: > 25% (content pages, services, blog posts, etc)
    • Ideal: > 30% (Core authority content or long-form guides)
  • 500 word minimum (as applicable to achieve signal density)
  • Reading level of 5th - 7th grade
  • 50 links or less
  • SEO friendly file names (be descriptive, no use of underscores, and use hyphens between words)
  • Text-based content above the fold
    • No JS rendered content above the fold
    • No hero images or sliders
  • No flash

Page Errors

  • Correct spelling
  • No broken links
  • No broken images
  • Able to load all resources (example: no mixed content over HTTPS)
  • No PHP errors or warnings
    • No closing php tag within a block of php.
      E.g. <?php ... PHP code here ... ?> <?php ... more PHP code ... ?> is incorrect
  • No JS errors
  • No CSS errors (W3C validation)
    • No use of !important
    • No use of @import
  • No HTML errors (W3C validation) and no warnings is highly preferred
    • No duplicate ID
    • Alternative text attribute on all images
      • Descriptive and relevant alternative text attribute on all images that provide context
      • An empty alternative text attribute on images that are decorative
    • Correct syntax and structure
    • Escape all characters
    • No typos, missing spaces, etc
    • No "obsolete" code
    • Correct use of HTML5 elements (nav, header, footer, section, aside, etc)
    • Form label for all form controls
  • WCAG/ADA compliance - WCAG 2.1 Level AA standards as a minimum
    • WCAG 2.2 Level AAA as the stated goal
    • No errors, or contrast errors (via WAVE) and no warnings is highly preferred
    • Supplemental manual testing as non-negotiable
  • Natural width and height for all images (<img width="50" height="100" src="..." alt="..." >).
  • Properly used code comments – HTML, CSS, JS, PHP etc
    • Comments are used for planning and reviewing, code description, algorithmic description, resource inclusion or debugging only.
    • No use of comments to remove or exclude code. No "commenting out" code.

Page Usability

  • A "good" experience across all browsers and devices
    • At a minimum: any major browser version released within the past 36 months
    • Easily achievable upon client request: Chrome (60 and up), Opera / Opera Mini (45 and up), Firefox (54 and up), Safari / Mobile iOS (10 and up), Edge (14 and up), Internet Explorer (9 and up), and Puffin
  • Fluid responsive grid
  • Large space between links on mobile
  • 1st link skips navigation (goes to content)
  • Readily recognizable links (not depending on color alone)
  • Readily recognizable focus state for links
  • Properly used page regions as applicable (header, main, nav, footer, etc)
  • ARIA roles as applicable (button, tablist, tabpanel, etc)
  • No skipped headings
  • Discernible links (links that use descriptive text or an aria-label or a descriptive title attribute)
  • No redundant links
  • No contrast errors
    • AA as a minimum (normal >4.5, large or bold >3.0)
    • AAA preferred (normal >7, large or bold >4.5)
  • Remove decorative items from the accessibility tree with aria-hidden
  • Include a descriptive title attribute for items with "suspicious" or nondescript link text
  • Well written @media print rules
  • Consider telephone numbers as links (tel:5551231234)
  • Click driven actions (as opposed to hover)
  • Breadcrumbs are highly recommended

PageSpeed Insights (as a guide)

PageSpeed Insights is a good, unbiased measure of general page usability.

A score of 100 across all four categories (mobile and desktop) is entirely possible (e.g. this page), but dependent on various choices.

The "gold standard" is above 90 for all four categories (Performance, Accessibility, Best Practices and SEO) - on both mobile and desktop. This is my officially stated goal for every website (or page) I build or fix.

A more pragmatic goal is:

  • A score of 100 for Accessibility, Best Practices and SEO - mobile and desktop
  • A Performance score above 80 via mobile
  • A Performance score above 90 via desktop

Privacy

General compliance with the strictest applicable privacy laws.

  • General Data Protection Regulation (GDPR) in the European Union
  • California Privacy Rights Act (CPRA)

Cookies

Using cookies is a choice; not a requirement! For websites that do not use cookies - notify users via the privacy policy. For websites that use cookies - load cookies after obtaining freely given, explicit, informed consent from users.

Metadata

  • Language/lang (matches document language)
  • Title tag (content less than 50 characters)
  • Description (less than 150 characters)
  • image_src
  • og:data
    • locale
    • type
    • title
    • description
    • url
    • site_name
    • image
      • secure_url
      • width
      • height
  • twitter:
    • card
    • description
    • title
    • image