Before this lesson
Complete the preceding lessons and prepare a small page with navigation, content and assets.
What you will be able to do
Configure language, title, encoding and viewport, distinguish markup errors from failed requests, and perform an evidence-based release check.
Understand the mechanism
Metadata describes the page to browsers and other consumers. A title should identify the current page rather than repeat only the site name, and a description should summarize rather than list keywords. Match the declared character encoding to the saved file. Bilingual pages need correct language metadata and stable counterparts, not merely translated navigation around untranslated content.
A classic external script can block HTML parsing. defer schedules classic scripts after parsing while preserving their document order; async suits independent work that does not rely on another script’s order. Loading once is not sufficient release evidence: caches can conceal missing resources, and an administrator session can hide public-access problems.
Runnable example
<!doctype html>
<html lang="en"><head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>HTML learning checklist | Honeysuck</title>
<meta name="description" content="Check structure, accessibility and asset loading before publishing.">
</head><body>
<main><h1>Release checklist</h1><ul>
<li>Check every internal link.</li><li>Inspect failed network requests.</li>
<li>Navigate using only the keyboard.</li></ul></main>
</body></html>Trace and verify
Run the full document and compare its tab title and main heading. On your own page, disable caching and reload, recording failed requests. Test narrow layouts and keyboard navigation, then check the public URL without an administrator session. Record each URL, expected behavior and observed result instead of a vague “tested” statement.
Common mistakes and boundaries
A viewport declaration does not make fixed-width content responsive. Avoid identical titles across pages and hidden keyword stuffing. Refreshing caches helps diagnose a problem but does not fix an incorrect path. Inspect the actual response content, not just an HTTP 200 status.
Practice challenge
Write six release checks covering structure, assets, keyboard use, mobile layout, language and public access. Record one real failure and its fix.
Reference solution and reasoning
Make checks reproducible: for example, the document fits a 375px viewport, or an image request returns 200 and the expected image. A login page returned with status 200 is still a failure. After fixing an issue, rerun affected checks and the related primary flow, retaining before-and-after evidence.