Skip to main content
GrN.dk

Main navigation

  • Articles
  • Contact
  • Your Digital Project Manager
  • About Greg Nowak
  • Services
  • Portfolio
  • Container
    • Excel Freelancer
    • Kubuntu - tips and tricks
    • Linux Apache MySQL and PHP
    • News
    • Image Gallery
User account menu
  • Log in

Breadcrumb

  1. Home

Rewrite index.html and index.php to the Root URL in Apache

Cleaning up /index.html and /index.php URLs is a small technical fix that often pays back in several places at once. It reduces duplicate entry points, makes analytics cleaner, and gives search engines a clearer signal about which URL you actually want indexed. It also avoids the awkward situation where campaigns, backlinks, and internal links all point at slightly different versions of the same page.

The original snippets on this page were pointing in the right direction, but they were split into separate rules for index.html, index.php, www, and https. In practice, that often creates extra redirect hops. The safer approach is to pick one final canonical URL and send every non-canonical request there directly.

Pick one canonical version first

Before touching Apache, decide what the public URL should be for every page:

  • Choose one host: either example.com or www.example.com.
  • Choose one scheme: normally https.
  • Remove explicit default documents such as /index.html and /index.php from public-facing URLs.

Do not enable both the www and non-www versions of the rule set. Pick one. The old non-www example also hard-coded http://, which can create an unnecessary extra hop or send users to the wrong protocol before another rule fixes it.

Recommended .htaccess pattern

If you only have access to .htaccess, this is a practical pattern for sending requests straight to the final non-www, HTTPS URL while removing index.html and index.php. Replace example.com with your real domain. This assumes the rules live in the document-root .htaccess.

<IfModule mod_rewrite.c>
RewriteEngine On

# Send explicit index files straight to the final canonical URL
RewriteCond %{THE_REQUEST} \s/+(.*/)?index\.(html|php)([\s?]|$) [NC]
RewriteRule ^(.*/)?index\.(html|php)$ https://example.com/$1 [NC,R=301,L]

# Canonicalize everything else to HTTPS + non-www
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC,OR]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
</IfModule>

If your brand standard is www.example.com, keep the structure and swap the target host. The important part is that every variant resolves to one final destination.

Why this works better than separate snippets

  • THE_REQUEST checks the original browser request line, so Apache only redirects when a visitor actually requested index.html or index.php. That helps you avoid interfering with internal rewrites used by CMSs and PHP apps.
  • The first rule sends http://www.example.com/index.php directly to https://example.com/ in one hop instead of stacking host, protocol, and file cleanup into multiple redirects.
  • Query strings are preserved by default when your target URL does not define a new one, so tracking parameters such as ?utm_source=... continue to work.
  • A permanent server-side redirect remains the right choice here. 301 is still a standard, safe option for a long-term canonical move.

Two edge cases teams forget

1. Reverse proxies and load balancers. If TLS is terminated before Apache, %{HTTPS} may always look like off. In that case, check the forwarded protocol header from the proxy you control instead:

RewriteCond %{HTTP:X-Forwarded-Proto} =http [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Only do this when your proxy overwrites that header on every request. Otherwise a direct request to the backend can spoof it.

2. ACME and certificate renewals. If you rely on HTTP validation for Let's Encrypt or another ACME client, make sure /.well-known/acme-challenge/ is exempted from a blanket HTTPS redirect or handled in the port 80 virtual host.

Use Apache config when you can

If you manage the full Apache virtual host, move the plain HTTP to HTTPS redirect out of .htaccess and into the port 80 vhost. Apache's own documentation prefers a dedicated Redirect there when possible. Keep .htaccess for path-level cleanup only when that is the access level you actually have.

Test the redirect map, not just the homepage

After deployment, test the variants that real users and crawlers are likely to hit:

curl -IL 'http://www.example.com/'
curl -IL 'http://example.com/index.php'
curl -IL 'https://www.example.com/folder/index.html?utm_source=test'

You want to see one permanent redirect to the final canonical URL, followed by a 200. If you see two or three hops, fix the rule order. Then update your internal links, XML sitemap, and canonical tags so your own site stops generating avoidable redirects for browsers and bots.

This is the kind of low-drama infrastructure cleanup that helps before a redesign, CMS migration, SEO handover, or performance pass. If you want an external consultant to rationalize the redirect rules and check the wider canonical setup at the same time, Greg can help without turning it into a big rewrite project.

Need help with this kind of work?

Need help untangling redirect rules, canonical URLs, or a migration plan? Start a practical conversation with Greg. Get in touch with Greg.

Sources

  • Redirecting and Remapping with mod_rewrite - Apache HTTP Server Version 2.4
  • Apache Module mod_rewrite - Apache HTTP Server Version 2.4
  • RewriteRule Flags - Apache HTTP Server Version 2.4
  • Redirects and Google Search - Google Search Central
  • How to Specify a Canonical with rel="canonical" and Other Methods - Google Search Central
Last modified
2026-06-06

Tags

  • apache
  • mod_rewrite
  • Technical SEO
  • Canonical URLs
  • Log in to post comments

Review Greg on Google

Greg Nowak Google Reviews

 

  • Rewrite index.html and index.php to the Root URL in Apache
  • Critical CSS for Faster Pages
  • Unable to Post in WordPress? Fix the Invalid JSON Response Error
  • Cloudflare AI Gateway Spend Limits Make LLM Cost Control a Real Ops Project
  • Tidy Up composer.json with Composer Normalize
RSS feed

GrN.dk web platforms, web optimization, data analysis, data handling and logistics.