The Ultimate Laravel .htaccess Guide for Shared Hosting (Hostinger & cPanel)

A few weeks ago, I spent almost an entire day fighting a 403 Forbidden error on Hostinger. I had deployed a beautiful Laravel app, the database was connected, and the code was perfect. But the server kept throwing a 403.

I was completely stuck. I tried every .htaccess snippet I found on Stack Overflow, but nothing worked. The breaking point was realizing that the Redirect directive in the root .htaccess conflicts violently with Hostinger’s mod_security rules.

As I looked at my Google Search Console this morning, I noticed a specific query surging: laravel shared hosting htaccess.

People are struggling with the exact same 403 errors I faced. If you are using Hostinger, GoDaddy, or similar cheap shared hosting for your Laravel application, this .htaccess guide is built specifically for you.

I am going to break down the exact two .htaccess files that run my production Laravel applications without a single 500 or 403 error. Here is the blueprint.

Section 1: The Architecture of Hostinger's File System

Before we write code, we have to understand how shared hosting environments like Hostinger handle file paths.

On Hostinger (and most cPanel hosts), your root domain is locked to the public_html folder. You cannot change the Document Root to public_html/public like you would on a VPS.

This means Laravel lives entirely inside public_html. However, Laravel's security rules require the public-facing files to live in the /public subfolder, and the sensitive core files (app/, vendor/, .env) to sit one level above it in public_html.

To make this work, we need a "gatekeeper" file: the Root .htaccess.

Section 2: The Root .htaccess (The Gatekeeper)

This file sits at the very top of your server (public_html/.htaccess). Its ONLY job is to catch all incoming traffic and silently route it into the public folder.

If you put anything else in here—like 301 redirects for old pages, or complex rewrite rules for specific files—you will trigger a 403 on Hostinger. We learned this the hard way.

Copy and paste ONLY this into your public_html/.htaccess:

<IfModule mod_rewrite.c>
    Options +FollowSymLinks
    RewriteEngine On

    RewriteCond %{REQUEST_URI} !^/public/
    RewriteRule ^(.*)$ public/$1 [L,QSA]
</IfModule>

Why this works: Options +FollowSymLinks tells the server it's okay to follow the symbolic links that Laravel creates. RewriteRule ^(.*)$ public/$1 takes any valid request (like shahzaib.tech/blog) and silently serves the file from public/blog. It does this without altering the URL visible in the user's browser.

Note: If you use a firewall or caching plugin in Hostinger's dashboard, this rule ensures those plugins still intercept the traffic correctly before it hits Laravel.

Section 3: The public/.htaccess (The Standard Laravel File)

You actually never need to touch this file once you deploy Laravel. It comes pre-configured with the framework.

This file lives at public_html/public/.htaccess. Its job is different: it handles the internal routing of your application after the Gatekeeper has directed the traffic to the public folder.

Do not edit this, but here is exactly what it does (the standard Laravel .htaccess):

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

    RewriteEngine On

    # 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>

It handles the graceful redirection of trailing slashes (e.g., shahzaib.tech/blog/ to shahzaib.tech/blog) and ensures that if a user requests a direct file that doesn't exist (like a fake CSS path), it bounces back to index.php so Laravel can handle the 404 error gracefully.

Section 4: How to Force HTTPS (Without Triggering a 403)

If you try to add RewriteCond %{HTTPS} off to your root .htaccess, Hostinger's mod_security will trigger a 403.

The safest, easiest, and most 403-proof way to force HTTPS on Hostinger is to not touch your .htaccess.

Instead, go to your Hostinger cPanel → Domains → SSL. You will see an option that says "Force HTTPS" (sometimes labeled "Auto-Redirect to HTTPS"). Enable that. Hostinger's native firewall will handle the redirect securely, and your .htaccess stays clean and lightweight.

Section 5: The 301 Redirect Trap (And How to Avoid It)

You have old static pages from a previous portfolio (/case-study-aurethe-ecommerce-platform.html). You need to send those users to the new pages so Google doesn't flag them as 404 errors.

If you put this in your root .htaccess:

Redirect 301 /case-study-aurethe-ecommerce-platform.html /projects/aurethe-ecommerce-platform

Hostinger will hit you with a 403 Forbidden.

The permanent, 100% safe solution: Because Laravel handles routing natively, we place redirects inside the Laravel application itself, not the server config.

Open your routes/web.php file and add this at the very top:

use Illuminate\Support\Facades\Route;

// Permanent 301 redirects for your legacy static files
Route::permanentRedirect('/case-study-aurethe-ecommerce-platform.html', '/projects/aurethe-ecommerce-platform');
Route::permanentRedirect('/index.html', '/');

Then, run:

php artisan route:cache

This means your redirects are now managed entirely by Laravel. They are testable, easily editable, and completely bypass Hostinger's blocking security rules.

Section 6: Where to Put Your robots.txt

Google often flags a "robots.txt blocked" error if the file is missing.

For a Laravel app on Hostinger, simply create a static file named robots.txt and place it inside your public_html directory (next to the root .htaccess).

Your public_html/robots.txt content:

User-agent: *
Allow: /

Sitemap: https://shahzaib.tech/sitemap.xml

Since Laravel's dynamic sitemap.xml route is located inside the public folder, this robots.txt file will safely point Google to the correct, dynamic location.

The Bottom Line on Hostinger .htaccess

The rule of thumb for Laravel on Hostinger is: Keep the root .htaccess minimal, and let Laravel handle the heavy lifting.

The root .htaccess is fragile. It is best used only as a router to the public folder. The moment you try to force it to handle redirects, HTTP headers, or HTTPS rewrites, you run the risk of a 403 error.

I used this exact two-file .htaccess setup to deploy the Almuneer LMS and the AURETHE jewelry platforms. It is stable, fast, and production-ready.

If you are migrating an existing static site to Laravel and need help safely redirecting your old URLs without breaking your server's security, feel free to check out my my full engineering portfolio or reach out to me directly. I specialize in clean, 403-free Laravel deployments.