You uploaded your Laravel app, opened the domain, and the homepage loaded just fine. Then you clicked a link, or typed/login, or /about straight into the address bar, and Apache handed you a flat, ugly 404. No route found. Nothing.

If that’s why you’re here, you’re dealing with a Laravel rewritebase 404 problem, and it’s one of the most common (and most misdiagnosed) issues in Laravel deployment. I’ve fixed this exact bug more times than I can count, on cPanel hosts, on VPS boxes, on subdomains buried three folders deep. The cause is almost always the same, and so is the fix. Let’s get into it.

What’s Actually Happening When the Laravel Homepage Works But Other Pages 404

Here’s the part that confuses most developers: if routing were completely broken, the homepage wouldn’t load either. But it does. So clearly something is working.

What’s actually working is the very first request. Apache serves index.php because that’s the default document for the folder, no rewriting required. Laravel boots, the router kicks in, and the home route resolves. Great.

But the second you click a link or refresh a non-root URL, Apache needs mod_rewrite to quietly redirect that request back to index.php so Laravel’s router can handle it. If the rewrite rules can’t figure out where your app actually lives, that redirect never happens. Apache goes looking for a real file or folder called /login or /dashboard, finds nothing, and throws its own 404. Not Laravel’s. Apache’s.

That distinction matters. It tells you exactly where to look.

Why This Laravel RewriteBase 404 Issue Happens in the First Place

Almost every Laravel homepage works; other pages 404 cases come down to one thing: the app isn’t sitting where the .htaccess file thinks it’s sitting.

Laravel ships with a .htaccess file inside the public folder that uses mod_rewrite to send every request through index.php. That file works perfectly when your project’s public folder is the actual document root. The trouble starts the moment you deploy into a subdirectory, a subdomain that maps to a folder, or a shared host that nests your app a level or two deeper than expected.

When that happens, the rewrite engine loses track of the base path it’s rewriting from. It’s still trying to match paths against the wrong starting point, so anything beyond the homepage falls through the cracks.

Other common triggers, in order of how often I actually see them:

• mod_rewrite isn’t enabled on the server at all.
• AllowOverride is set to None in the Apache config, so .htaccess rules are ignored entirely.
• The public folder’s .htaccess got skipped, renamed, or overwritten during upload.
• The app was deployed into a subfolder without updating RewriteBase.

The .htaccess RewriteBase Laravel Fix, Step by Step

If your Laravel app lives in a subfolder, like example.com/blog/, this is almost certainly your fix.

Open the .htaccess file inside your public directory. It should already contain Laravel’s default rewrite block. Add a RewriteBase line right after RewriteEngine On, matching your actual subfolder path:

<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews -Indexes
    </IfModule>

    RewriteEngine On
    RewriteBase /blog/

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.+)/$
    RewriteRule ^ %1 [L,R=301]

    # Send Requests To Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

A few things to get right here, because small mistakes in this step cause the exact same symptom to come right back:

The RewriteBase path needs a leading and trailing slash. It should match the URL path to your app, not the server’s file path. If your app answers at example.com/blog/, the value is /blog/, full stop.

Save the file, clear your browser cache (or test in incognito), and hit a non-home route directly. If it resolves, you’ve found your fix.

While you’re in there, it’s worth double-checking your .env file too. Set APP_URL to match the real, public-facing URL, subfolder included. Laravel uses this for generating absolute links, and a mismatched APP_URL causes its own quiet trail of broken assets and redirects later on.

Laravel Subfolder 404 Error: What Changes Outside the Root

Running Laravel outside the domain root introduces a few extra wrinkles beyond just fixing the Laravel RewriteBase 404 error, and this is the part people skip.

Your asset paths need to resolve correctly too. If you’re linking CSS or JS with hardcoded root paths like /css/app.css instead of using Laravel’s asset() helper, they’ll 404 right alongside your routes, even after the RewriteBase fix. Swap them for {{ asset('css/app.css') }} and let Laravel build the correct path using your APP_URL.

Named routes and redirects should always go through route() or url() helpers rather than hardcoded strings. It’s a small habit, but it’s the difference between an app that survives being moved to a different folder and one that breaks every time.

If you’re running Laravel behind a reverse proxy or load balancer inside that subfolder setup, check TrustProxies too. It’s a separate issue, but it produces symptoms that look suspiciously similar: partial functionality, broken redirects, links that go nowhere.

Apache mod_rewrite Laravel Not Working? Check These First

Not every Laravel RewriteBase 404 error is actually a RewriteBase problem. mod_rewrite itself might not be doing anything, and no amount of .htaccess editing will fix that.

Run this on your server to confirm the module is actually loaded:

apache2ctl -M | grep rewrite

If nothing prints, the module isn’t enabled. On Ubuntu or Debian, turn it on with:

sudo a2enmod rewrite
sudo systemctl restart apache2

Next, check AllowOverride. Even with mod_rewrite active, Apache ignores .htaccess files entirely unless the virtual host config explicitly permits it. Open your site’s config (usually under /etc/apache2/sites-available/) and confirm your public directory block looks like this:

<Directory /var/www/example.com/public>
    AllowOverride All
    Require all granted
</Directory>

If AllowOverride is set to None, every rewrite rule you write is invisible to Apache. This one gets missed constantly because the server “looks” configured correctly at a glance, and the failure only shows up once you click past the homepage.

Laravel Deployment 404 Shared Hosting: cPanel-Specific Fixes

Shared hosting adds its own quirks on top of everything above, and a Laravel deployment 404 shared hosting issue is really just another flavor of the Laravel RewriteBase 404 error.

Most shared hosts point your domain’s document root straight at public_html, not at Laravel’s public folder. If you’ve dropped your entire Laravel project into public_html as-is, the app is technically running from the wrong directory, and no RewriteBase value will fully patch that over.

The cleanest fix, if your host allows it: upload everything except the public folder’s contents outside of public_html (a sibling directory works well), then move the contents of Laravel’s public folder into public_html itself. Update the two path references at the top of public_html/index.php so they point to the new location of your vendor and bootstrap/app.php files.

If you can’t restructure folders like that, check whether your host offers “Application Manager” or similar tooling for Laravel, cPanel-based hosts increasingly do, and it handles this path mapping for you automatically.

Also worth checking on shared hosting specifically: PHP version mismatches. If your host defaults to an older PHP version than your composer.json requires, Laravel can fail to boot in ways that mimic a routing problem. Set the correct PHP version through cPanel’s “MultiPHP Manager” before you go chasing rewrite rules. If you’re still deciding on a host, our comparison of shared hosting providers for Laravel apps breaks down which ones handle this document root problem cleanly out of the box.

The Better Long-Term Fix: Point Your Domain Straight at /public

Editing RewriteBase solves the immediate Laravel RewriteBase 404 problem, but it’s a workaround, not the ideal setup. Laravel’s own documentation is clear about this: the public folder is meant to be your web server’s actual document root.

If you’re on a VPS or dedicated server where you control the Apache or Nginx config, set the document root directly to your project’s public folder instead of routing around a subfolder:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com/public

    <Directory /var/www/example.com/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

With this setup, you don’t need RewriteBase at all in most cases. Your app runs from the root of its own document space, exactly how Laravel expects, and this whole category of bug disappears. It also keeps everything outside public, your .env, your models, your config files, off the public internet entirely, which is a real security win, not just a tidiness one.

If restructuring your hosting isn’t an option right now, the RewriteBase fix from earlier will hold up fine. Just keep this in your back pocket for your next deployment.

Quick Checklist Before You Deploy Again

Run through this before your next push, and you’ll likely never see the Laravel RewriteBase 404 error again:

• .htaccess is present inside public, and it wasn’t stripped out by your deployment script or Git ignore rules.
• RewriteBase matches your actual subfolder path, if you’re using one.
• mod_rewrite is enabled on the server.
• AllowOverride All is set for your app’s directory.
• APP_URL in .env matches your real, public-facing address.
• Asset references use asset(), url(), or route() rather than hardcoded paths.
• Where possible, your document root points at public directly.

Work through that list once, and the Laravel RewriteBase 404 error stops being a recurring headache.

FAQ

Why does only my homepage work in Laravel? Because the homepage doesn’t need rewriting; the server serves index.php as the default file. Every other page depends on mod_rewrite successfully redirecting the request, which is what breaks in a Laravel RewriteBase 404 scenario.

Do I always need RewriteBase in Laravel’s .htaccess? No. If your app’s public folder is the actual document root, Laravel’s default .htaccess works without it and you won’t run into the Laravel RewriteBase 404 error at all. You only need RewriteBase when the app runs from a subfolder.

I added RewriteBase, and it’s still 404ing. What now? Double-check that mod_rewrite is enabled and that AllowOverride All is set on the server itself. A correct RewriteBase value does nothing if the server is ignoring .htaccess altogether.

Is this the same issue on Nginx? Conceptually yes, though Nginx doesn’t use .htaccess at all. You’d fix it with a try_files directive in your server block instead. Worth a separate deep dive if that’s your stack.

For further reading, Laravel’s own deployment documentation covers server requirements in detail, and Apache’s mod_rewrite documentation is the definitive source if you want to understand exactly what these directives are doing under the hood. If you’re setting up your very first Laravel server, our guide to configuring a fresh VPS for Laravel deployment walks through the document root setup from scratch, and it pairs well with this fix.

Deploy it, click through every page, not just the homepage, and confirm before you call it done. That five-minute habit saves you the 2 am “why is production broken” message every single time.