A complete website is a collection of connected destinations, not a homepage with a convincing screenshot. The hardest part of a first command-line website build is often deciding what “complete” means. Without that definition, it is easy to finish the hero section while leaving the contact page, mobile navigation, article routes, and deployment files unfinished.
This walkthrough approaches the build as a sequence of small deliverables. The examples describe a developer resource site with guides and articles, but the same planning method works for a product brochure or technical portfolio. Use the CLI website builder overview alongside this guide to keep the scope focused on public, static content.
Write a route inventory first
List every public destination before working on colors. Start with the homepage, the main topic pages, about, contact, and the blog. Add an article route for each planned post. If category or tag pages will appear in navigation, include them too. A menu label represents a commitment to produce a useful destination, not an excuse to add an empty page.
Give each route a primary reader question. The homepage explains the overall value. A topic page develops one concept. An article answers a narrower practical question. The contact page explains how to reach the site owner. When two planned pages answer exactly the same question, combine them or clarify their different purposes before drafting.
Record the route, page title, main heading, content owner, and intended next step in a simple inventory. This makes omissions visible early. It also provides a reference for later tests: the build is not complete until every promised route exists and can be reached through an appropriate internal link.
Separate source from published files
Create a working directory for content and templates, and a different directory for the public result. That boundary prevents internal notes or temporary data from being uploaded accidentally. The Hugo directory-structure documentation illustrates how an established static-site tool separates content, layouts, assets, and configuration. You can apply the underlying separation without adopting every directory it uses.
For a small hand-authored site, the public directory can contain an index document at its root, one directory per page, and a shared assets directory. Keep generated screenshots and quality reports outside that public directory unless they intentionally belong on the website. A deployment package should contain the website, not the developer's entire workspace.
Decide which files are authoritative. If a generator produces article HTML from Markdown, edit the Markdown rather than patching the generated page. Otherwise, the next build will erase the correction. Put this rule in the handoff notes so another maintainer does not discover it by losing work.
Establish one reusable page shell
Build a single shell containing the document metadata, header, navigation, content region, and footer. Reuse it for every page. This is how a corrected email address, a new navigation label, or an accessibility improvement reaches the entire site instead of only the homepage.
Keep the shell independent from individual page content. It should accept a title, description, canonical address, and page body. Article pages can add their dates and article metadata, while standard content pages remain simpler. A shell that depends on one specific article title will be difficult to reuse cleanly.
Test the extremes early
Before expanding the site, render a short page and a long page through the shell. Long titles, multiple paragraphs, and narrow screens reveal problems that a short demo cannot. Confirm that the footer stays below the content and that sticky navigation does not hide anchored headings.
Build one route end to end
Choose a representative topic page and finish it completely. Write its copy, add an image where it communicates something useful, connect the navigation, create its metadata, and test its final address. This first finished route is your implementation reference for all the others.
Use actual content rather than generic filler. A realistic paragraph reveals line length and spacing problems, while a meaningful button label tests the available width. The contact email should already be correct. The page should still make sense when images do not load or JavaScript is disabled.
Once the reference page works, use its patterns rather than copying and independently modifying entire documents. Shared construction reduces accidental drift. If you later change the header, you should not need to remember which of twenty copied pages still contains the previous version.
Add content in coherent groups
Build the core topic pages together, then the blog system, then the supporting pages. For each group, finish the navigation and cross-links before moving on. This creates useful intermediate states rather than a directory full of unrelated drafts that only becomes connected at the end.
Give blog articles a predictable structure: one main heading, an introduction, clearly named sections, a conclusion, related reading, and a publication date. The article index should show a useful excerpt rather than the first arbitrary characters of the body. Category pages need context explaining what a reader will find there.
Reserve time for the unglamorous destinations. About and contact pages help people understand the resource and reach its owner. A sitemap and feed support discovery outside the visual navigation. None of these files is a substitute for useful content, but missing them weakens an otherwise thoughtful handoff.
Treat interaction as a promise
Every interactive element needs a real outcome. A menu button opens and closes the menu. A copy button copies a specific visible prompt. A download link delivers a file. A link labeled “read the guide” opens a completed guide. Avoid account, install, or generate buttons when the corresponding capability does not exist.
For a static site, a browser-based prompt library can be genuinely useful without pretending to execute remote models. Let users choose a documented template, read it, copy it, or save it locally. Explain the boundary at the relevant location: the prompt runs in their chosen tool, not on the website.
Test interactions with both a mouse and a keyboard. Confirm that focus is visible, the mobile menu can be closed, and an unsuccessful clipboard operation has an understandable fallback. A polished interface includes the failure path, not only the ideal click sequence.
Preview the deployed shape
Serve the public directory with a local HTTP server rather than judging only individual files opened from disk. Visit nested paths directly and refresh them. This checks the directory structure that a static host will actually serve. A page reached through the homepage can still fail when someone opens its address in a new tab.
Inspect shared assets from nested pages. A relative image path that works at the root may resolve to the wrong directory deeper in the site. Use a consistent linking strategy and test it across several levels. The same check applies to stylesheets, scripts, favicons, and downloadable prompt files.
Package the public directory's contents at the archive root. After extraction, the server should find the homepage immediately rather than requiring someone to move an enclosing project folder. Test a fresh extraction, not only the working directory, because packaging errors are distinct from page errors.
Conclusion: finish the whole journey
A reliable first build starts with routes and ends with a tested artifact. Reuse one page shell, finish a representative route, add connected groups of content, and make every interaction truthful. The CLI-to-complete-websites workflow turns these steps into release checkpoints. The goal is not the fastest first screenshot; it is a website whose pages, links, assets, and deployment instructions all agree with one another when a new visitor arrives.
