OctoberCMS routes every front-end request through a single index.php entry point. When a visitor opens a page like /blog/my-first-post, there is no physical file or folder at that path. The web server must silently hand the request to index.php, which then reads the URL, matches it against a page's route definition, and renders the correct Twig markup. If that rewrite step fails, OctoberCMS never sees the real path, and the server returns its own generic 404 or an Apache directory listing instead of your themed content.

On a managed LiteSpeed stack running AlmaLinux and CloudLinux, LiteSpeed reads your .htaccess rules natively, so the Apache-style directives October ships with work without translation. The problems hosting users actually run into are narrower: a missing or overwritten .htaccess, duplicate content served under both www and non-www hostnames, mixed HTTP and HTTPS canonicals that split your SEO signals, and sitemaps that either never generate or point at the wrong protocol. Every fix below stays inside your hosting account, no root or SSH daemon required.

Restoring the core rewrite engine in .htaccess

The first thing to confirm is that OctoberCMS actually shipped its .htaccess into your document root and that it was not stripped during an upload. Open cPanel > Files > File Manager (or DirectAdmin > File Manager), navigate to public_html, and enable Show Hidden Files (dotfiles) from the settings gear in the top-right corner. You should see a .htaccess alongside index.php, artisan, and the bootstrap, config, and modules directories.

If the file is missing or has been emptied, recreate it. Click + File, name it .htaccess, then edit it and paste the standard OctoberCMS front-controller rules:

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Protect hidden files and framework internals
    RewriteRule ^(\.(?!well-known).*) - [F,L,NC]
    RewriteRule ^(bootstrap|config|vendor|tests|storage/cms/[^/]+/[^/]+/protected)/.* index.php [L,NC]
    RewriteRule ^(system|modules/[^/]+)/([^/]+/)+[^/]+\.(htm|php|p)$ index.php [L,NC]
    RewriteRule ^(system|modules/[^/]+)/([^/]+/)+(.*\.(txt|yaml|bak|sql))$ index.php [L,NC]

    # Allow requests to themes assets only
    RewriteRule ^themes/[^/]+/(layouts|pages|partials)/.* index.php [L,NC]

    # Standard front controller
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^.*$ index.php [L]
</IfModule>

The last three lines are the heart of friendly URLs: if the requested path is not a real file (!-f) or a real directory (!-d), it is routed to index.php. The earlier blocks are security rules that stop visitors from reading raw .yaml, .htm, or SQL files out of your theme and module folders. Keep those intact; removing them to "simplify" the file exposes configuration data.

One subtlety trips up installs placed in a subfolder or on an addon domain. If OctoberCMS lives in public_html/october rather than the web root, add a matching base so relative rewrites resolve correctly:

RewriteBase /october/

After saving, test a deep URL such as /account or a known blog post. A working rewrite returns your themed page; a broken one returns a plain Apache/LiteSpeed 404 with no October styling. If you still see failures, check your local error log at cPanel > Metrics > Errors or the error_log file File Manager drops into the same directory as index.php, which records the exact path LiteSpeed tried to resolve.

Enforcing HTTPS and a single canonical hostname

Search engines treat http://site.com, https://site.com, http://www.site.com, and https://www.site.com as four separate addresses. Serving the same page under all four dilutes ranking signals and can trigger duplicate-content handling. Pick one canonical form and redirect the rest with a single 301, placed above the RewriteEngine On block's front-controller section but after it is enabled.

To force HTTPS and strip www (the most common choice), insert these rules just inside the <IfModule mod_rewrite.c> block, before the front-controller rule:

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

    # Strip www
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

On LiteSpeed behind a shared proxy, %{HTTPS} is usually set correctly, but if your SSL terminates upstream and the variable reads off on secure requests you will hit a redirect loop. In that case swap the condition to inspect the forwarded header:

    RewriteCond %{HTTP:X-Forwarded-Proto} !https
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Before adding redirects, make sure your certificate covers the canonical hostname. Issue or verify it under cPanel > Security > SSL/TLS Status (AutoSSL) or DirectAdmin > Account Manager > SSL Certificates with Let's Encrypt. Redirecting to HTTPS before a valid certificate exists produces browser warnings that are worse than mixed content.

Finally, align October's own base URL so generated links, canonical tags, and sitemap entries all use the same scheme and host. Edit config/app.php through File Manager and set the url value explicitly:

'url' => env('APP_URL', 'https://site.com'),

If a .env file exists in the root, set APP_URL=https://site.com there instead, since .env overrides the config default. A mismatch between APP_URL and your .htaccess canonical is the usual reason sitemaps and <link rel="canonical"> tags still emit http:// after you have forced HTTPS.

Sitemaps, static pages, and taming 404s

OctoberCMS does not generate an XML sitemap out of the box. Most sites use the RainLab.Sitemap plugin together with RainLab.Pages. Install them from Settings > Updates > Install plugins in the backend (the backend lives at /backend by default). Once active, open CMS > Sitemap (or the Sitemap section under Pages) and add definitions mapping your content types—static pages, blog posts, categories—to URL priorities and change frequencies. The plugin then serves a live sitemap at /sitemap.xml built from your current routes, so it never goes stale the way a hand-written file does.

Because that sitemap is produced by the front controller, its URLs inherit APP_URL. If you corrected the scheme in the previous section and the sitemap still shows old links, clear October's cache: delete the contents of storage/framework/cache and storage/cms/cache via File Manager, or run php artisan cache:clear from cPanel > Advanced > Terminal if your plan exposes it. For robots.txt, create a plain file in public_html pointing crawlers at the sitemap:

User-agent: *
Allow: /
Sitemap: https://site.com/sitemap.xml

Unexpected 404s inside October usually come from one of three sources. First, a page's URL property in CMS > Pages may not match the link you are testing—October routes are defined per page in the url = "/blog/:slug" header, and a typo there breaks only that route while the rest of the site works. Second, case sensitivity on Linux means /Blog and /blog are different paths; normalise internal links to lowercase. Third, moved or renamed content needs explicit 301s so old inbound links and search results keep working. Add those near the top of .htaccess:

    RewriteRule ^old-page/?$ /new-page [R=301,L]

For a soft 404 that returns styled content rather than a bare server error, create a page in the backend with the URL set to /404; October renders it automatically for unmatched routes. If you prefer diagnosing framework-level failures, the same log-reading discipline used for other Laravel-based apps applies here—check storage/logs and the document-root error_log, an approach we cover more broadly in our error diagnosis guide for shared hosting. After every rewrite change, hard-refresh and retest both a canonical redirect and a deep page so you confirm the file-exists condition and the host redirect work together rather than fighting each other.