Clean URLs aren't just aesthetically pleasing. To most of us, they're essential for professional web development, better SEO rankings, and improved user experience.

Instead of showing https://webcomm.dev/about.html, your visitors see https://webcomm.dev/about.

Whether you're a developer managing client sites or a cPanel user maintaining your own website, we hope that this tutorial will help walk you through creating clean URLs using Apache's mod_rewrite module via both cPanel and command line interface (CLI)

What You Need Before Starting

Before diving in, ensure you have:

  • Access to cPanel or SSH credentials for your server
  • mod_rewrite enabled on your Apache server
  • Existing .html files in your website's directory
  • Basic understanding of file management and text editing

Good news: The mod_rewrite module is already enabled on virtually all WebHostingM hosting environments, so you can proceed with confidence.

Why Clean URLs Matter for Your Website

Clean URLs provide multiple benefits that directly impact your website's success. It's clean, professional, and easy to remember. It inspires confidence and shows you're a detail-oriented business owner. Done right, this small change can elevate your marketing and makes your brand unforgettable.

What Happens When URLs Go Wrong

Let's address the challenges you might face without clean URLs:

SEO

Search engines index both /about.html and /about as separate pages, creating duplicate content penalties. Your site drops in search rankings, and potential customers can't find you.

Implementing proper 301 redirects ensures search engines understand which version is canonical, consolidating your SEO authority into one authoritative URL.

First Impression

A potential client visits your portfolio site and sees URLs like portfolio.html and contact-form.html. They question whether you're technically capable of handling their project.

Clean URLs signal technical competence and attention to detail, exactly what clients want to see.

Migration

There may come a time when you need to migrate from static HTML to a dynamic CMS or change your tech stack. Every URL change breaks existing links, social shares, and bookmarks.

Clean URLs let you change the underlying technology without affecting external links. Your /services URL works whether it's served by services.html, services.php, or a modern JavaScript framework.

The Basic Two Approaches For Clean URLs

You have basic two methods to implement clean URLs, and this largely will depend on your comfort level and access:

  • Method 1: cPanel File Manager: This is perfect for users without SSH access or those who prefer a visual interface
  • Method 2: Command Line (CLI): If you are a developer, VPS customers, and/or with root access, of course you may prefer terminal workflows

Both methods achieve identical results. You are likely to choose the one that matches your workflow.

The Rewrite Rules You Need

At the heart of this transformation is a small configuration file called .htaccess.

You just need to add a production-ready snippet of code to it.

We've combined the best rules to not only make your new links work but also to automatically redirect anyone who uses an old .html link.

This is fantastic for your SEO and user experience.

htaccess

        # Turn on the rewrite engine
        RewriteEngine On

        # --- Redirect old .html URLs to clean versions (301 permanent redirect) ---
        # This ensures SEO-friendly consolidation and prevents duplicate content
        RewriteCond %{THE_REQUEST} .html
        RewriteRule (.*).html$ /$1 [R=301,L]

        # --- Internally map clean URLs to actual .html files ---
        # Serves the .html file without showing the extension in the browser
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule (.*) $1.html [L]

This does similar thing:


    # Turn on the rewrite engine
    RewriteEngine On

    # --- Rule to redirect webcomm.dev/page.html to webcomm.dev/page ---
    # This makes sure old links are SEO-friendly and don't break
    RewriteCond %{THE_REQUEST} \.html
    RewriteRule (.*)\.html$ /$1 [R=301,L]

    # --- Rule to internally map webcomm.dev/page to webcomm.dev/page.html ---
    # This makes the new, clean links work behind the scenes
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule (.*) $1.html [L]
    

Let's break down what each section does:

  • RewriteEngine On – Activates Apache's URL rewriting capability
  • First RewriteRule – Redirects any request containing .html to the clean version with a 301 (permanent) status code. This tells search engines the page has permanently moved.
  • RewriteCond %{REQUEST_FILENAME} !-f – Checks if the requested URL is NOT an existing file
  • RewriteCond %{REQUEST_FILENAME} !-d – Checks if the requested URL is NOT an existing directory
  • Second RewriteRule – Internally rewrites clean URLs to their .html counterparts, serving the actual file

Method 1: Using cPanel File Manager

This visual approach is the most straightforward method and probably for most cPanel users with no technical command-line knowledge. Follow these steps carefully:

Step-by-Step Instructions

  1. Log in to your cPanel account

    Access your hosting control panel using the credentials provided by your hosting provider.

  2. Navigate to File Manager

    In the Files section of cPanel, click on File Manager. This opens your website's file system in a browser-based interface.

  3. Enable hidden files visibility

    Click the Settings button in the top-right corner. In the dialog that appears, check the box labeled "Show Hidden Files (dotfiles)" and click Save. This is critical because .htaccess files start with a dot and are hidden by default.

  4. Navigate to your website's root directory

    In the left sidebar, click on public_html (or your domain's document root if different). This is where your website files live.

  5. Locate or create the .htaccess file
    • If .htaccess exists: Right-click the file and select Edit
    • If .htaccess does NOT exist: Click the + File button, name it .htaccess, click Create New File, then right-click and select Edit
  6. Add the rewrite rules

    If a dialog appears asking about encoding, click Edit to proceed. Paste one of the complete code from the section above into the editor. Important: If your file already contains content (such as WordPress or other CMS rules), paste the new code at the very top of the file, right after any existing RewriteEngine On line or at the beginning.

  7. Save your changes

    Click the Save Changes button in the top-right corner of the editor.

  8. Test your clean URLs

    Visit your website using a clean URL (e.g., https://example_domain.com/about instead of https://example_domain.com/about.html). The page should load successfully. Also test the old .html URL; it should redirect to the clean version.

Method 2: Using Command Line Interface (CLI)

This method is faster for developers and those comfortable with terminal commands will prefer this approach. You'll need SSH access to your server.

Step-by-Step Instructions

  1. Connect to your server via SSH
    $ ssh username@$servername.com

    Replace username with your SSH username and $servername.com with your server's hostname or IP address.

  2. Navigate to your website's document root
    $ cd public_html

    If your site is in a subdirectory or has a different document root, adjust accordingly (e.g., cd /var/www/html).

  3. Check if (dot)htaccess exists
    $ ls -la

    This lists all files, including hidden ones. Look for .htaccess in the output.

  4. Edit the (dot)htaccess file
    $ vim .htaccess

    You can also use vim or any text editor you prefer. For example, nano is recommended for beginners due to its simplicity.

  5. Add the rewrite rules

    Paste the complete code from the "The Rewrite Rules You Need" section. If the file already contains content, add the new rules at the top.

  6. Save and exit

    If using nano:

    • Press Ctrl+O (Write Out) to save
    • Press Enter to confirm the filename
    • Press Ctrl+X to exit

    In vim:

    • Press Esc to ensure you're in command mode
    • Type :wq and press Enter (write and quit)
  7. Verify file permissions (optional but recommended)
    $ chmod 644 .htaccess

    This sets appropriate read/write permissions for security.

  8. Test your implementation

    Changes take effect immediately. Visit your site using clean URLs to verify everything works correctly.

Troubleshooting Checklist

Since mod_rewrite is already enabled on your server, here are the most common issues and their solutions, arranged in order of likelihood:

1. Browser Caching Issues

issue or symptom: Changes don't appear to work, or old URLs still show.

possible solution: Your browser has cached the old behavior. Try these steps:

  • Clear your browser cache completely
  • Use a private/incognito window for testing
  • Use a different browser you haven't used for the site
  • Try accessing from a different device
  • Use Ctrl+Shift+R (or Cmd+Shift+R on Mac) for a hard refresh

2. Conflicting Rewrite Rules

issue or symptom: Site breaks, 500 Internal Server Error, or rules don't work as expected.

possible solution: Other rules in your .htaccess file may be interfering. Common culprits include:

  • WordPress default rules
  • Laravel or other framework rules
  • Security plugin rules
  • Previous custom rewrite attempts

Best practice: Place your clean URL rules at the very top of the .htaccess file, immediately after RewriteEngine On, before any CMS or framework rules.

3. Incorrect File Location

issue or symptom: Rules have no effect at all.

possible solution: The .htaccess file must be in the same directory as your HTML files. For most sites, this is public_html.

If your site is in a subdirectory like public_html/mysite, the .htaccess file should be in mysite, not in public_html.

4. Syntax Errors in .htaccess

issue or symptom: 500 Internal Server Error immediately after saving changes.

possible solution: A single typo can break the entire file. Check for:

  • Missing or extra spaces
  • Incorrect brackets or parentheses
  • Wrong directive names
  • Copying issues (smart quotes instead of straight quotes)

Copy the code exactly as provided, or restore your previous working .htaccess file and try again.

5. Missing HTML Files

issue or symptom: 404 Not Found errors when accessing clean URLs.

possible solution: The rewrite rules check if the corresponding .html file exists. Ensure:

  • The .html file actually exists in the correct directory
  • File names match exactly (case-sensitive on Linux servers)
  • File permissions allow the web server to read them

6. Sites in Subdirectories

issue or symptom: Rules work inconsistently or not at all on sites not in the root directory.

possible solution: If your site is in a subfolder (e.g., webcomm.dev/mysite/), add a RewriteBase directive at the top. Check our KB for examples or documentation(s).

8. Verifying mod_rewrite is Active

While mod_rewrite is enabled by default on most servers, you can verify it's actually active:

For users with PHP access: Create a file (since this may be disabled for shared hosting packages, please contact our team to enable this access for you before doing this) named info.php in your public_html directory:

info.php
<?php phpinfo(); ?>

Visit https://example_domain.com/info.php and search (Ctrl+F) for "mod_rewrite". If it appears in the Loaded Modules section, it's active. Important: Delete this file after checking for security reasons.

For VPS/root users via CLI:

For RHEL, CentOS, or Fedora VPS/root users via CLI:

$ httpd -M | grep rewrite

Or:

$ apache2ctl -M | grep rewrite

You should see rewrite_module (shared) in the output.

Optional Enhancements

Handling Both .html and .php Extensions

If you have a mix of .html and .php files (as often the case in most hosting environments), you can extend the rules:

Multi-extension Clean URLs

        RewriteEngine On

        # Redirect .html extensions
        RewriteCond %{THE_REQUEST} .html
        RewriteRule (.*).html$ /$1 [R=301,L]
        
        # Redirect .php extensions
        RewriteCond %{THE_REQUEST} .php
        RewriteRule (.*).php$ /$1 [R=301,L]
        
        # Serve .html files for clean URLs
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteCond %{REQUEST_FILENAME}.html -f
        RewriteRule (.*) $1.html [L]
        
        # Serve .php files for clean URLs
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteCond %{REQUEST_FILENAME}.php -f
        RewriteRule (.*) $1.php [L]
      

Adding Trailing Slashes

As a developer, you may prefer URLs with trailing slashes (/about/ instead of /about). So add this rule:

Enforce Trailing Slashes

      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_URI} !(.*)/$
      RewriteRule ^(.*)$ /$1/ [R=301,L]

Forcing HTTPS

Combine clean URLs with HTTPS enforcement for maximum security and professionalism:

Force HTTPS with Clean URLs

      RewriteEngine On

      # Force HTTPS
      RewriteCond %{HTTPS} off
      RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
      
      # Your clean URL rules follow...
      

Testing and Verification

After implementing clean URLs, perform these tests to ensure everything works correctly:

1. Basic Functionality Test

  • Visit a clean URL (e.g., /about) – should load successfully
  • Visit the old .html URL (e.g., /about.html) – should redirect to /about
  • Check that the browser's address bar shows the clean version after redirect

2. HTTP Status Code Verification

Use browser developer tools or online tools to verify proper 301 redirects:

  • Open browser DevTools (F12 or right-click → Inspect)
  • Go to the Network tab
  • Visit an old .html URL
  • Check that the status code is 301 Moved Permanently

3. SEO Impact Check

Use tools like Google Search Console, Screaming Frog, or similar to:

  • Ensure no duplicate content issues
  • Verify canonical URLs are correct
  • Check for broken internal links

4. Multiple Browser Testing

Test in multiple browsers (Chrome, Firefox, Safari, Edge) and devices (desktop, mobile, tablet) to ensure consistent behavior.

この回答は役に立ちましたか? 0 ユーザーが役に立ったと評価しました (0 票)