Static HTML Files Not Being Displayed with WordPress

If you've uploaded a static HTML file to your WordPress site's directory and it shows a 404 error or loads your WordPress theme instead of the HTML page, the problem is WordPress's permalink rewrite rules. WordPress intercepts nearly all requests and routes them through its own system, which means your standalone HTML file never gets served directly by Apache.

01. Why This Happens

When WordPress is installed, it adds rewrite rules to the .htaccess file in your public_html directory. These rules look like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

The key conditions are RewriteCond %{REQUEST_FILENAME} !-f and !-d, which mean "if the requested file doesn't physically exist and isn't a directory, route it through WordPress." In theory, if your HTML file physically exists, Apache should serve it directly.

However, there are situations where this breaks:

The file was uploaded to the wrong location - If the file isn't in the exact path Apache expects, the "file exists" check fails and WordPress takes over.

Nginx reverse proxy is caching - On Ultra Web Hosting servers, ea-nginx sits in front of Apache. Nginx may be serving a cached WordPress 404 response instead of checking for the file directly.

Permalink conflicts - If you have a WordPress page or post with the same slug as your HTML filename (e.g., a page called "about" and a file called about.html), WordPress claims the URL first.

02. The .htaccess Fix

The most reliable fix is to add an explicit rule that tells Apache to serve your HTML file directly, bypassing WordPress entirely. Add this above the # BEGIN WordPress block:

# Serve static HTML files directly
RewriteEngine On
RewriteRule ^mypage\.html$ - [L]
RewriteRule ^landing/(.*)$ - [L]

# BEGIN WordPress
...

The [L] flag means "last rule" - Apache stops processing rewrite rules and serves the file as-is. The first line handles a single file, the second handles an entire subdirectory of static files.

03. Using a Subdirectory

A cleaner approach for multiple static HTML pages is to put them in their own subdirectory with a separate .htaccess file that prevents WordPress from interfering:

public_html/
  wp-config.php
  .htaccess          (WordPress rules)
  static/
    .htaccess        (empty or minimal - no WordPress rules)
    page1.html
    page2.html
    css/
    images/

The static directory's .htaccess can simply contain:

RewriteEngine Off

This disables all rewrite rules within that directory, so Apache serves files directly without WordPress involvement.

04. Using a Subdomain

If you have a significant amount of static HTML content, creating a subdomain (like pages.yourdomain.com) is the cleanest separation. The subdomain gets its own document root with no WordPress installation, so there's no conflict at all.

1. Create the subdomain in cPanel - Go to Domains > Subdomains (or Domains on newer cPanel versions)
2. Upload your HTML files - Upload to the subdomain's document root (usually /home/username/pages.yourdomain.com/)
3. No additional configuration needed - Apache serves the files directly

05. Embedding HTML in a WordPress Page

If you don't need a completely separate HTML file and just want to use custom HTML within your WordPress site, you can create a WordPress page and paste your HTML into it:

Block Editor (Gutenberg): Add a "Custom HTML" block and paste your HTML code directly into it.

Classic Editor: Switch to the "Text" tab (not "Visual") and paste your HTML.

This approach keeps everything within WordPress, maintains your site's header/footer/navigation, and avoids any rewrite conflicts. The trade-off is that WordPress's CSS may interfere with your custom HTML styling.

Quick Recap: Static HTML with WordPress

1. Check file location - Make sure the HTML file physically exists at the exact path
2. Add .htaccess rule - Put a RewriteRule above the WordPress block to serve the file directly
3. Use a subdirectory - Put static files in a folder with RewriteEngine Off
4. Consider a subdomain - Cleanest option for significant amounts of static content
5. Avoid slug conflicts - Don't name HTML files the same as existing WordPress pages

Last updated March 2026 · Browse all WordPress articles