CodeIgniter 4 on Hostinger: Homepage Works, but Other Routes Return 404

If your CodeIgniter homepage opens on Hostinger but /services returns 404, check which part of the request is failing. The web server may be looking for a physical services directory instead of handing the URL to CodeIgniter. The application can also return 404 if the requested path, HTTP method or route group does not match. The homepage alone cannot distinguish these cases.

The quickest useful test is to compare one known GET route with and without index.php in the URL. Start on a staging site or disposable copy so you can inspect the result without disrupting real traffic. CodeIgniter troubleshooting

1. Confirm the route exists on the deployed copy

Run this in the application directory that contains spark, using the PHP version intended for the site.

php -v
php spark routes

Look for the route’s HTTP method, path and handler. A route registered as POST cannot be tested by opening the URL in a browser, which sends GET. A route inside an admin group may be available at /admin/services even though its local declaration is services. If you use host-specific routes, add --host with the staging hostname on CodeIgniter 4.4.0 or later. Check matching route order and any filters before changing server rules. CodeIgniter routing and the Spark route table

For a reproducible check on a disposable copy only, add this route to app/Config/Routes.php. Register it above any broad application catch-all. The route returns a fixed marker and reads no data.

$routes->get('health-check', static function () {
    return service('response')
        ->setStatusCode(200)
        ->setContentType('text/plain')
        ->setBody("ci4-route-ok\n");
});

Run php spark routes again and confirm that GET health-check is listed. If the app already has this path, choose another unique test name and use it consistently. A site-wide filter may still redirect you to sign-in, so run the test through the staging environment’s normal access controls. CodeIgniter defined routes · CodeIgniter response methods

2. Compare the clean URL and the front controller

Replace the example host. Run the same commands before and after each change. All three requests use GET and show response headers so you can see a redirect before following it.

base='https://staging.example.com'

curl -sS -i "$base/health-check"
curl -sS -i "$base/index.php/health-check"
curl -sS -i "$base/ci4-no-such-route-6f21"

Use the exact marker ci4-route-ok to identify a response from your test route. A general error template can look like a normal page, even if the server returned 404. If you see a redirect, verify its destination before following it. A redirect to the home page or sign-in page is a different result from the test marker.

If only the front-controller URL returns the marker, CodeIgniter can handle the route. Check how the web server forwards the clean URL. If both return 404, the comparison has not isolated rewriting. Check the deployed route, actual document root, bootstrap path and filters first. Some server configurations do not pass path information after index.php. If the clean URL works but the front-controller URL fails, clean routing already works. CodeIgniter troubleshooting

3. Verify which folder Hostinger serves

CodeIgniter expects the web server to serve its public/ files. Hostinger documents public_html as the usual website root and says its Web and Cloud plans do not let you change the home directory from the panel. Check the exact root for the staging hostname in hPanel before moving files. CodeIgniter deployment · Hostinger website root guide

When your account permits a sibling application directory outside that web root, the framework’s two-directory approach can look like this.

staging site directory/
├── ci4-app/
│   ├── .env
│   ├── app/
│   ├── spark
│   ├── vendor/
│   └── writable/
└── public_html/
    ├── .htaccess
    ├── index.php
    └── assets/

Copy the contents of the framework’s public/ directory, including hidden files, to the actual document root. Keep the application and secrets outside it. In the deployed index.php, locate the line that loads app/Config/Paths.php. In the layout above, the corresponding path is __DIR__ . '/../ci4-app/app/Config/Paths.php'. Change that path to match your installed version and actual layout. Confirm that PHP can read it before changing rewrites. If the host restricts access to sibling directories, confirm the supported layout with Hostinger. CodeIgniter two-directory deployment

4. Restore clean routing, then test the surrounding site

Check whether .htaccess made it into the document root during upload. On a server that supports Apache-style rewriting, use the public/.htaccess shipped with the same CodeIgniter release as your app as a reference. On an existing site, compare it to your current file before editing. Preserve working HTTPS and hostname redirects, existing file and directory exceptions, and routes used by other parts of the site. If the host does not honor the file or the relevant rewrite directive, check the host’s rules for that account. CodeIgniter URL configuration · Apache per-directory rewrite rules

After the clean URL returns the marker, check baseURL and indexPage in the application configuration. An empty indexPage tells CodeIgniter’s URL helpers to generate links without index.php. It does not configure web-server rewriting. If you deliberately deploy below a subdirectory, test generated URLs against that path. CodeIgniter URLs

Before the edit, save a copy of each affected file outside the public directory. For example, if the only changed file was public_html/.htaccess, restore the exact copy you saved, such as cp -p ci4-app/rollback/htaccess.before public_html/.htaccess from the staging site directory. If you also changed the front controller or app configuration, restore those matching versions together. Retest the homepage, one real route, a static asset and a missing route. Remove the temporary test route when finished.

The proof of recovery is a real clean URL that returns its intended response, with ordinary missing URLs still returning 404. For a release checklist and a way to plan recovery before changing a live site, see our DevOps guide for small website teams. For a broader review of what belongs outside the public directory, see our website security guide.

Test scope · The walkthroughs use a disposable application, example hostnames and a disposable database account. The HTTP status codes and MySQL responses in the tables are expected results for the stated setup. They were not observed on a Hostinger server.