Dreamweaver .dwt Templates and Site Definitions: Managing Static Layouts Across Local, Testing, and Production Servers

The problem: consistent layouts without a build system

If you maintain a static HTML site with dozens of pages, repeating the same header, navigation, and footer in every file is a maintenance liability. Dreamweaver's .dwt template system offers a direct answer: define the shell once, mark the areas that change per page as editable, and let Dreamweaver propagate structural edits to every child page. The catch is that templates only work cleanly when combined with a disciplined Site Definition that accounts for local, testing, and production paths.

How .dwt templates enforce structure

The template file and editable regions

A Dreamweaver template is an HTML file saved with a .dwt extension. Everything outside an editable region is locked; Dreamweaver will overwrite those areas in every child page when you run an update. Inside the template, you mark editable areas with HTML comment pairs. The following example shows a minimal template with one editable region:

<!-- template.dwt -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Page Title</title>
    <link rel="stylesheet" href="css/site.css">
</head>
<body>
    <header>
        <img src="images/logo.png" alt="Logo">
        <nav>
            <a href="index.html">Home</a>
            <a href="services.html">Services</a>
        </nav>
    </header>
    <main>
        <!-- InstanceBeginEditable name="MainContent" -->
        <p>Default content. Replace this in each child page.</p>
        <!-- InstanceEndEditable -->
    </main>
    <footer>
        <p>Contact: [contact removed]</p>
    </footer>
</body>
</html>

In this file, the header, nav, and footer elements are locked. The MainContent region is editable. When you save a .dwt file inside a defined site, Dreamweaver creates a Templates folder and displays the file with a template icon in the Files panel.

Generating child pages and updating them

To create a page from the template, use File > New > Page from Template (or the equivalent in your version's New Document dialog), select the site and template, and choose a layout if prompted. Dreamweaver generates a child HTML file that contains the same InstanceBeginEditable and InstanceEndEditable comments. You edit only the content between those markers.

When the template changes—for example, you add a new navigation link or update the footer—you propagate the change by choosing File > Update Pages and selecting Entire Site or a specific page range. Dreamweaver rewrites the locked regions in every child page while preserving whatever text and markup exist inside the editable regions. This is the core engineering trade: you gain centralized control over layout, but you lose the ability to make arbitrary structural changes in individual child pages.

Multi-environment publishing with Site Definition

Templates control page structure; Site Definition controls where files live and how links resolve. Before publishing, define a site with a Local Root Folder (for example, /Users/name/sites/project or C:\sites\project) and add remote servers under the Servers category. A typical static project defines at least two remotes: a Testing server (e.g., ftp://staging.example.com) and a Production server (e.g., ftp://www.example.com).

The critical decision inside Site Definition is the link path strategy. Dreamweaver resolves links relative to the site root or the document location, but it does not rewrite absolute paths for you at publish time. The table below compares common path styles and their behavior after upload:

Path style	Example	Behavior after publish
Absolute local file path	file:///C:/sites/project/images/logo.png	Broken; points to the author's local disk, not the web server.
Absolute URL	http://localhost/images/logo.png	Broken on remote hosts; resolves to the local machine, not Testing or Production.
Site-root relative	/images/logo.png	Works only if the remote web root matches the local root folder exactly.
Document relative	../images/logo.png	Works when the directory structure is preserved between local and remote servers.

For most static sites, document-relative links are the safest choice because they travel with the folder structure. If you use site-root relative links, verify that the remote server's web root is mapped to the same subdirectory as your Local Root Folder.

Limits and common mistakes

Dreamweaver templates are static. They do not support conditional includes, server-side logic, or component composition beyond nested editable regions, and support for deeply nested editable regions is limited. Renaming a .dwt file after child pages exist requires manually re-linking those children; Dreamweaver does not reliably track renames across the site.

The most damaging mistake is editing a child page in an external editor such as VS Code or Notepad++. Those editors may strip or reorder the InstanceBeginEditable and InstanceEndEditable comments, which breaks the link between the child and the template. Once the markers are gone, Dreamweaver treats the page as a standalone document and future template updates will not apply.

A second common error is injecting custom CSS or scripts into a child page outside the editable region—for example, adding a <style> block directly under the <head> tag. Because Update Pages replaces the entire non-editable area, that custom code is discarded on the next update. Any per-page styling must live inside an editable region or in an external stylesheet that is already linked from the template.

Finally, path case matters. Many web hosts run case-sensitive file systems. If your local folder references Images/Logo.png but the remote server stores images/logo.png, the link will break after publishing even though it worked locally. Check the Files panel and remote directory listing for case mismatches before and after upload.

Verifying the workflow

Before relying on templates for a production site, run a controlled verification:

1. Create a new Dreamweaver site with a Local Root Folder and save a .dwt template containing one editable region.
2. Generate two child pages from the template and confirm in Code view that both contain the InstanceBeginEditable and EndEditable comments.
3. Edit a locked element in the template—such as the footer text—and run File > Update Pages > Entire Site. Open both children and confirm the footer changed while the content inside MainContent remained intact.
4. Add a Testing server in Site Definition using an FTP or SFTP profile, publish the site, and open the remote URLs in a browser. Check that images, stylesheets, and navigation links resolve.

Because Update Pages modifies files in place, keep the site under version control or create a backup before running a site-wide update on an established project. If an update overwrites unexpected content, restoring from version control is faster than manually reconstructing editable regions.

Menu names and panel layouts vary between Dreamweaver versions, but the .dwt marker format and the Site Definition server model have remained consistent across recent releases. Verify the exact menu labels in your installation, and treat any behavior that differs from the description above as a version-specific variation to confirm against Adobe's current documentation.