Hand-Coded Static HTML vs WordPress: When a Static Site Wins (Lessons From Our Own Site)

Why We Are Writing About Our Own Website

Most “static site vs WordPress” articles are written from the outside. This one is not. The website you are reading, pixelsproagency.com, is hand-coded static HTML. There is no WordPress install behind it, no database, and no page builder. Each page is a plain .html file sitting in the public_html folder of a GoDaddy cPanel hosting account, with one shared stylesheet, one shared JavaScript file, and a small PHP script that handles the contact form.

We build plenty of WordPress sites for clients, and for many of them WordPress is the right answer. We have covered that broader decision in WordPress vs a custom website. This article is narrower and more practical. It covers what running a hand-built static site is actually like week to week, the problems we ran into, how we work around them, and the situations where a static site clearly beats WordPress — and where it does not.

What “Static HTML” Means Here

A static site serves files exactly as they are stored. When a visitor requests blog.html, the web server reads that file from disk and sends it. Nothing is assembled at request time. A WordPress page, by contrast, is built on every uncached request. PHP runs, the theme and plugins load, the database is queried, and the HTML is generated and sent.

“Hand-coded” adds one more condition: there is no build tool generating those files either. Somebody writes or edits the HTML directly. That is the purest form of static, and it is where both the biggest advantages and the most annoying chores come from.

Where the Static Site Has Been Genuinely Better

Speed without a caching stack

With no PHP or database work per request, the server’s part of page load is small and predictable. We do not run a caching plugin, an object cache, or a page-cache layer, because there is nothing to cache that is not already a file. That does not make a static site automatically fast. Large images, web fonts, and third-party scripts such as analytics and ad code still need the same care described in our website speed optimization guide. On a lean static page, those third-party scripts are often the heaviest thing left.

A much smaller attack surface

There is no wp-login.php for bots to hammer, no plugin with an unpatched vulnerability, and no admin user with a weak password. What remains is the hosting account itself (cPanel and FTP credentials), the contact form handler, and whatever third-party scripts the pages load. That list is short enough to actually review, which matters more than it sounds.

No update treadmill

A WordPress site needs core, theme, and plugin updates, and someone has to check that the site still works afterwards. A static HTML file written today will render the same way years from now. Our maintenance list is mostly about content, links, and the form — not about version numbers.

Total control of the markup

Every tag on the page is there because someone put it there. When we decided each article should have exactly one <h1> and that the banner title should be a styled paragraph instead of a second heading, it was a direct edit, with no theme overrides and no page builder fighting back. The same goes for structured data, canonical tags, and Open Graph tags.

The Problems We Actually Ran Into

The duplicated header and footer

This is the big one. With no templating, every page contains its own full copy of the top bar, header, navigation, mobile menu, and footer. The site has more than fifty HTML files, so adding one link to the footer means changing more than fifty files. The Editorial Policy link that now sits beside Privacy Policy and Terms of Service at the bottom of every page is a good example: one link in principle, dozens of separate edits in practice, each one easy to get wrong by hand.

The trap is that the copies are not quite identical. The navigation marks the current page with an active class, so the Blog link is “active” on blog pages and the Services link on service pages. A blind find-and-replace of the whole header would wipe that out. The approach that works is a small script that replaces only the exact fragment that changes, and reports any file where that fragment was not found exactly once. Here is the pattern, using that footer link as the example:

# add_footer_link.py: run from the site root, after taking a backup
from pathlib import Path

OLD = '<a href="terms-of-service.html">Terms of Service</a></span>'
NEW = ('<a href="terms-of-service.html">Terms of Service</a> · '
       '<a href="editorial-policy.html">Editorial Policy</a></span>')

changed, missing = [], []
for page in sorted(Path('.').glob('*.html')):
    html = page.read_text(encoding='utf-8')
    if NEW in html:
        continue                      # already updated
    if html.count(OLD) == 1:
        page.write_text(html.replace(OLD, NEW), encoding='utf-8')
        changed.append(page.name)
    else:
        missing.append(page.name)     # fragment absent or duplicated

print(f'Updated {len(changed)} files')
print('Check by hand:', ', '.join(missing) or 'none')

The script reports how many files changed and lists any page where the old fragment was missing. Those are the pages that had already drifted, and they need checking by eye.

Templating without a CMS

There are proper fixes for duplication, each with a cost:

• Server Side Includes (SSI). Apache SSI can stitch a shared header.html into each page with an include directive. It usually means renaming pages to .shtml or changing server configuration — and changing every URL is not something to do casually on an indexed site.
• PHP includes. The same idea using <?php include 'header.php'; ?>. Again, either the files become .php or the server has to be told to run PHP inside .html, which also adds PHP work to every request.
• A static site generator. Tools such as Eleventy or Hugo keep partials and layouts in source files and output plain HTML to upload. This is the cleanest long-term option. It adds a build step and a toolchain that whoever maintains the site has to understand.
• Loading the header with JavaScript. Fetching a header file in the browser looks tempting. It delays navigation rendering, can cause layout shift, and makes key links depend on a script running. We avoid it.

<!-- Apache Server Side Include: needs mod_include enabled -->
<!--#include virtual="/partials/header.html" -->

<!-- PHP include: the page must be processed by PHP -->
<?php include __DIR__ . '/partials/header.php'; ?>

For now we have stayed with plain files plus careful scripted edits, because the URLs are established and the header changes rarely. If the site grew much larger, moving to a generator that outputs the same filenames would be the next step.

Forms need server-side code anyway

HTML can display a form, but it cannot send an email. Our contact form posts to contact-submit.php, a short script that validates the fields and sends the message with PHP’s mail() function on the GoDaddy server. It also includes a hidden honeypot field to catch bots and a simple per-session throttle. One hosting-specific detail matters: the “From” address has to be an address on our own domain, or the host’s mail relay may not deliver the message. With WordPress, a form plugin handles all of this. On a static site, you either write and maintain that script or use a third-party form service.

Sitemaps, listings, and counts are all manual

WordPress regenerates the XML sitemap, the blog index, category pages, and “recent posts” widgets automatically. On a hand-coded site, publishing one article means touching several files: the article itself, the card on blog.html, the latest guides on the home page, the <url> entry with its lastmod date in sitemap.xml, the human-readable sitemap.html, and anywhere the site mentions how many guides it has. Miss one and you get a post Google cannot discover quickly, or a page claiming the wrong number of articles.

<url>
    <loc>https://www.example.com/blog-new-article.html</loc>
    <lastmod>2026-10-09</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.7</priority>
</url>

We handle this with a written publishing checklist and a link checker that confirms every internal link points to a file that exists. It works, but it is real effort that WordPress simply does not ask of you.

Static HTML vs WordPress Side by Side

Practical trade-offs from running both kinds of site

Task	Hand-coded static HTML	WordPress
Publishing a new post	Copy a template, edit HTML, update listings and sitemap by hand	Write in the editor and press Publish
Changing the header or footer	Edit every file, ideally with a script	Edit once in the theme or menu settings
Contact forms	Write a server script or use a form service	Install and configure a form plugin
Security upkeep	Hosting credentials and the form handler	Core, theme, and plugin updates plus login protection
Server work per page view	Read a file	PHP and database, unless cached
Who can edit content	Someone comfortable with HTML	Anyone with an account
E-commerce, bookings, memberships	Needs external services or custom code	Mature plugins such as WooCommerce

When a Static Site Wins

1. A developer maintains the site anyway. If edits already go through a technical person, a CMS adds upkeep without saving anyone time.
2. Content changes occasionally, not daily. Brochure sites, portfolios, single-service landing pages, and event microsites fit well.
3. Security and low maintenance are priorities. A site that should keep running untouched for long stretches is safer with no plugins to fall out of date.
4. You want exact control over markup and performance. Static pages make it easy to keep the HTML lean and the structure precise.

When WordPress Is the Better Choice

• Non-technical staff need to publish or edit content themselves, often.
• You need a store, bookings, memberships, or multilingual content. Plugins solve these far faster than custom code.
• The site will grow to hundreds of posts with categories, tags, and archives that should update themselves.
• Several people with different roles need to draft, review, and publish.

If you are leaning towards WordPress, our website maintenance guide describes the ongoing care it needs, so you can budget for it from the start.

Common Mistakes With Static Sites

• Editing live files on the server. Keep a local copy as the source of truth, keep a backup of what is live, and upload changed files deliberately. We keep a list of changed files for every batch of edits so an upload never misses one.
• Find-and-replace across the whole site without checking the result. Always count matches before and after, and review a sample of pages in a browser.
• Forgetting the sitemap and listings. A new page that nothing links to and that is missing from sitemap.xml can sit undiscovered for a long time.
• Leaving forms unprotected. A PHP form script without validation and a honeypot or similar check becomes a spam relay quickly.
• Assuming static means fast. Uncompressed images and stacked third-party scripts slow a static page as easily as a WordPress one.

Frequently Asked Questions

Is a static HTML website better for SEO than WordPress?

Search engines do not rank a page higher because it is static. Static pages can be very fast and give full control over markup, which helps, but content quality, internal links, and technical basics matter far more than the platform.

Can a static HTML website have a contact form?

Yes, but the form needs something on the server or a third-party service to process it. On cPanel hosting a short PHP script using mail() is common. It should validate input and include spam protection such as a honeypot field.

How do you update the header and footer on a static site?

Without templating, each page has its own copy, so changes must be made in every file. A careful script that replaces one exact fragment and reports files where it was not found works well. Server Side Includes, PHP includes, or a static site generator remove the duplication entirely.

Do static sites need maintenance?

Less than WordPress, but not zero. You still update content, check links, keep sitemap.xml current, protect hosting credentials, and look after any server-side form script.

When should I choose WordPress instead of static HTML?

Choose WordPress when non-technical people need to publish often, when you need e-commerce, bookings or memberships, or when the site will grow to hundreds of posts with categories and archives that should update automatically.