A website can pass a build command and still be difficult to use. Navigation may work only with a mouse, a sticky header may cover an anchored heading, or a long article title may force the mobile layout wider than the screen. Release review needs to examine those visitor experiences alongside the files and metadata.
This checklist is designed for a small static publication built from a command-line workflow. It combines structural checks with practical browser testing. It is not an accessibility certification or a guarantee of compatibility with every device. It is a repeatable way to catch important problems before handing the site to its owner.
Establish a representative test set
Choose pages that exercise different layouts: the homepage, a standard topic page, a long article, an archive, and the contact page. Include a page with a long heading and one with several images. Testing only the homepage leaves much of the shared system unexplored.
Write down the viewport sizes and browser conditions you use. Include a narrow phone layout, a tablet-sized view, and a desktop view. Test at increased text size or browser zoom as well. The purpose is not to collect attractive screenshots; it is to discover where content stops fitting or controls become difficult to reach.
Keep the route inventory beside the test plan. A page absent from your sample still needs basic link, metadata, and asset checks. Combine broad automated coverage with deeper manual inspection of representative layouts instead of expecting either method to replace the other.
Check the document before the decoration
Inspect the page's main heading and section structure. The W3C guidance on headings explains how headings communicate page organization and support navigation. Use headings to describe the content hierarchy, not merely to obtain a desired font size.
Look for one clear primary heading, meaningful section headings, and an identifiable main content region. A repeated site wordmark does not need to become the main heading on every article. Breadcrumbs should help explain the page's place in the site without replacing its actual title.
Check reading order when columns collapse on mobile. A sidebar, illustration, or related-content block should not interrupt the article in a confusing place. The order in the document should remain understandable even when the visual layout is simplified or the stylesheet is unavailable.
Walk through the site with a keyboard
Use the keyboard to move through navigation, menus, links, disclosure controls, and copy buttons. Confirm that focus is visible at every step and that its order follows a sensible path. A control should not become unreachable because its visual position differs from its place in the document.
Test opening and closing the mobile navigation. Verify that the expanded state is communicated and that closing it returns the interface to a usable state. An Escape-key action can be helpful, but it should not be the only way to close the menu. Keep the visible toggle available.
Check the landing position of anchors
Check a skip link that moves past repeated navigation to the main content. After following it, the content should be visible rather than hidden beneath the sticky header. Repeat the same check with article table-of-contents links, which often reveal insufficient scroll spacing on long pages.
Inspect contrast and non-color cues
Evaluate body text, secondary labels, buttons, and focus indicators against their actual backgrounds. A saturated palette can still be readable, but some bright combinations provide poor separation. Do not assume that a neon color is accessible simply because it appears vivid.
Make important states understandable without color alone. An active navigation item can include a shape or text treatment, and a copy result should state what happened. A red or green dot by itself is not enough to explain success or failure to every visitor.
Check the site in different interaction states. A button may have readable default text but poor contrast on hover. A focused link can disappear into a dark panel if the outline is not considered. Test the states people encounter, not only the resting screenshot used in a design review.
Review images as content
Confirm that every referenced image exists and has explicit dimensions. Inspect the image at the size where it appears in the interface. A large typography card may look clear when opened directly but become unreadable when cropped into a narrow landscape thumbnail.
Write alternative text that conveys the image's purpose in context. A featured graphic can describe its subject and short headline; a purely decorative icon may need no spoken description. Avoid filling alternative text with keyword lists that do not help someone understand the page.
Look for accidental duplication. When an image repeats a nearby heading exactly, a long description of every decorative element may add noise. Choose an appropriate concise description and keep essential instructions in real page text rather than embedding them only inside artwork.
Test motion and progressive enhancement
Review animated tickers, hover effects, and decorative transitions. Provide a way to pause persistent motion where appropriate and respect reduced-motion preferences. The page's meaning should not depend on seeing an animation complete or following text as it moves across the screen.
Disable JavaScript and inspect the basic experience. Important content and ordinary links should remain available. A copy button may require JavaScript, but the prompt text should still be readable and its file downloadable. Do not hide the entire article while waiting for a reveal script that may fail to run.
Test failure states for enhanced controls. Clipboard access can be unavailable in some contexts. A helpful response explains how to select the visible text or use the download link instead of reporting success that never occurred. A truthful failure message is part of the feature.
Validate routes, metadata, and feeds
Check every internal destination against the public directory. Verify nested routes, fragment identifiers, stylesheet paths, script paths, image references, and downloadable files. A link can point to a valid page but an invalid section identifier, so test both parts when an anchor is present.
Review titles, descriptions, canonical addresses, and structured data for uniqueness and consistency. Compare article dates across the page, listing, metadata, and feed. The clean URL and metadata guide explains why these surfaces should come from one content record.
Parse the sitemap and RSS feed, then inspect representative entries manually. Ensure that feed article bodies contain usable links outside the original site context. A file being valid XML is necessary, but it does not establish that the links, descriptions, and dates are correct.
Test the exact handoff package
Extract the release archive into a fresh directory and serve that directory locally. Confirm that the homepage sits at the archive root and that nested pages work without custom rewrite rules. This catches packaging mistakes that the original development preview cannot reveal.
Check the final file inventory for missing assets and unintended private material. Remove unused template logos, old demo scripts, and development-only files that do not belong in the public website. A clean package is easier to inspect and reduces confusion for the person deploying it.
Record the tested conditions and outstanding limitations. Local browser checks do not validate a live domain's certificate, cache behavior, or host configuration. The CLI-to-complete-websites guide treats the final live-site smoke test as a separate deployment responsibility.
Conclusion: release evidence, not reassurance
A useful release checklist produces observable results: working routes, readable layouts, keyboard-reachable controls, included images, consistent metadata, and a correctly packaged artifact. Keep the checks repeatable so a future editor can run them after a shared template change. No single automated score captures the whole visitor experience. Combine structural validation with real browser interaction, document what you tested, and make the final release correspond to the exact files that passed that review.
