HTML Website Templates / Static Web Guide
How to Add New Pages to an HTML Website Template
Add HTML template pages with suitable layouts, unique metadata, correct paths, discoverable links and a repeatable maintenance process.
To add a page to an HTML website template, copy an appropriate source layout, replace its content and metadata, then add links that make it discoverable. Check asset paths and direct access after publication. If the package generates HTML from partials or other source, add the page through that documented system.
Creating a file does not complete the task. The new page also needs a clear purpose, a suitable address and a place in the site’s navigation or content hierarchy.
Decide why the page deserves its own address
Write down the question the page answers and how it differs from existing pages. A dedicated service explanation should provide useful detail, rather than repeat the homepage under a new heading.
Consider how visitors will arrive. A service page may be linked from an overview, while a case study may be linked from relevant services and a project index.
The HTML template overview explains how page planning fits the wider project. A small content outline helps you choose the correct layout before copying files.
Identify the editable source
A direct-edit package may store each page as an HTML document. Another package may use partials, includes or a generator to create those documents.
Read the README and inspect the build scripts if present. Do not add a page only to an output directory that will be replaced during the next build.
Make a recoverable copy or a version-control checkpoint. Then use the closest existing interior layout as a starting point. A detailed service page is usually a better base for another service than a homepage with many unrelated sections.
Choose a consistent address
Follow the site’s existing URL convention. A simple package might use commercial-surveys.html. Another may use a commercial-surveys folder containing index.html.
Check how the intended host serves those paths before changing conventions. Do not assume that a local preview’s fallback behaviour matches production.
Avoid spaces and ambiguous filenames. Keep letter case consistent in both filenames and links. If replacing an existing address, plan redirects or update references deliberately rather than silently breaking old links.
Replace page-specific metadata
Update the title, description, visible main heading and any social preview information. Review canonical markup if the package supplies it, using the final public address for the new page.
Check structured data and breadcrumbs too. A copied service page should not continue describing the original service or pointing to its old URL.
Search the new file for phrases from the source page. This catches demonstration names, image captions and links that are easy to miss when only the main paragraph is changed.
Check paths from the new location
Relative paths depend on the document’s directory. A stylesheet path that works from the root can fail when a page moves into a nested folder.
For example, a document at services/survey.html may need a different relative path to a root-level assets directory than index.html uses. Root-relative paths begin at the domain root and can be convenient, but need special consideration when a site is hosted beneath a subpath.
MDN’s link guidance explains relative references. Test images, scripts, stylesheets and document links from the new address instead of checking navigation alone.
Add useful routes to the page
Link from the relevant overview and from other pages where the new explanation helps the reader. Use descriptive anchor text that makes the destination understandable.
Not every page belongs in the primary header. A site with several detailed services can use a Services overview rather than adding an increasingly long row of navigation items.
If navigation is repeated across HTML files, update every required copy. If it is maintained in a shared partial, change the partial and regenerate output. The single-page versus multipage comparison explains the maintenance trade-off.
Refresh indexes and site-wide files
Check whether the new page belongs in a project index, service list or generated search index. Review sitemap generation and include the correct public URL through the site’s existing process.
A hand-maintained sitemap requires a deliberate update. A generated sitemap may pick up the new route automatically, but confirm the output rather than assuming.
Do not add a page to the sitemap if it is an unpublished draft or otherwise not intended for public discovery. Keep its publication state consistent across the actual site and generated indexes.
Test content and interaction
Visit the new page directly and through its internal links. Check the main heading, metadata, images, buttons and any form behaviour.
Inspect it at several widths with realistic content. A copied layout can break when a longer heading or differently shaped photograph is inserted. Follow the responsive template checks for the affected elements.
Review the page as a visitor who has not read the homepage. It should provide enough context to understand the offer and a clear next step without forcing unnecessary backtracking.
Record a repeatable process
Once the first added page is correct, document the files and indexes that needed changes. That becomes a useful checklist for future additions and handover.
Inspect the HTML catalogue for packages with suitable interior layouts before starting a larger project. Adding pages is straightforward when the template’s structure is understood; keeping metadata, links and shared elements consistent is what makes the result maintainable.