A practical launch walkthrough for your first static HTML site.
Test a real visitor journey, check a missing page, and distinguish local success from a website that works on its public domain.
Start with one complete visitor journey
Before uploading a folder of HTML, decide which journey matters most. For a publication, that might be homepage to category, category to article, and article to another useful page. Carry out the journey rather than checking the homepage alone. Write down what you expected at each step and what happened. This gives you a small acceptance checklist that describes the site's purpose, not just whether its files exist.
Check the layout with real content
Open a long article, a page with a long heading, and a page with images. Narrow the browser window and check whether words, navigation, and controls remain readable. Pay attention to the least tidy content you actually plan to publish. A short sample heading can hide wrapping problems. If an image has not loaded yet, does the page reserve appropriate space? A layout should work throughout the reading process, not only after everything finishes downloading.
Take the keyboard journey too
MDN describes accessibility as enabling people to use the web across different needs and circumstances. Try reaching navigation links and controls using the keyboard. Notice whether you can see the focused element and whether the order makes sense. Read form labels and image alternatives in context. These checks are a starting point, not a full accessibility audit or a certification of compliance. If your site depends on a particular interaction, test that interaction rather than assuming a visually tidy page is usable.
Test the pages that are easy to overlook
Check contact details, privacy information, and any search or menu controls. Submit a search that should return a known article and another that should return nothing. If you publish a contact form, confirm that it really delivers a message; otherwise use an appropriate contact link. Also request a page that does not exist. A missing address should produce the intended error behavior rather than an unrelated homepage that leaves a visitor unsure what happened.
Give each page a clear identity
Google Search Central recommends descriptive page titles and meta descriptions, crawlable links, and a sitemap where useful. Use page-specific titles rather than repeating one generic label everywhere. A sitemap helps discovery; it does not guarantee that every URL will be indexed. Keep your public domain separate from a local preview address when generating canonical URLs. Check the actual output after building, because a correct configuration file is not proof that the generated HTML uses it.
Verify the upload structure
Your homepage file needs to be in the document root configured for the intended domain. If a host expects index.html directly in that directory, an extra enclosing folder changes where the file can be reached. Keep editable source files and private configuration out of public uploads. Retain a copy of the exact release files you uploaded so you can compare them with a later change. Before replacing an existing website, keep a recoverable backup of its current contents.
Repeat the journey on the actual domain
After publishing, return to the original visitor checklist using the HTTPS address readers will use. Check a deep article link directly, not only by navigating from the homepage. Confirm images load, the contact route makes sense, and the missing-page behavior is still correct. Hosting configuration, domain connection, and browser caching can produce differences that a local preview cannot establish. Record the public result and any unresolved issues. A successful launch means the intended visitor journey works where visitors will actually take it.
AI-generated illustration
AI-generated illustration