WHMCS ships with three URL formats, and the difference between them decides whether your client area looks like index.php?rp=/store/web-hosting or the cleaner store/web-hosting. The clean version is not just cosmetic. Friendly URLs are what search engines index, what clients bookmark, and what you paste into knowledgebase articles. When these break, the symptom is almost always the same: the homepage loads fine, but every product, announcement, or knowledgebase link returns a 404 Not Found. That single behavior points to a rewrite engine that is not being invoked, and on a LiteSpeed shared hosting account you can resolve it entirely from your own toolset.

Why WHMCS friendly URLs break on shared hosting

WHMCS reads its URL format from the General Settings stored in the database, not from a config file you can casually edit. Under Configuration (spanner icon) → System Settings → General → SEO, the Friendly URLs dropdown offers three choices: Basic (query-string style, always works), Mod Rewrite / SEO Friendly (requires a working rewrite module and an .htaccess file), and WHMCS SEO / Search Engine Friendly where available. The moment you select the mod_rewrite option, WHMCS starts generating links like https://billing.example.com/store/web-hosting throughout the client area. Those links only resolve if the web server rewrites them back to index.php internally.

The breakage happens because the required .htaccess file is missing, misnamed, or contains rules the server ignores. WHMCS provides a template file named .htaccess.txt in the root of the installation. During a fresh install or an upgrade over FTP, that file frequently stays as .htaccess.txt and is never renamed to .htaccess, so LiteSpeed has no rewrite instructions to follow. Another common trigger is uploading WHMCS into a subfolder, such as public_html/billing/, without adjusting the RewriteBase to match that path. In both cases the homepage still works because index.php is a real file, while every friendly path fails because nothing maps it to that script.

LiteSpeed Web Server, which powers Hostiso's stack, reads Apache-style .htaccess directives natively, so the standard WHMCS rules apply without translation. You do not need to enable a module or touch a server config. Everything needed sits inside your account's document root, editable through cPanel → File Manager (Jupiter theme) or DirectAdmin → File Manager (Evolution). The key habit is enabling Show Hidden Files (dotfiles) in the File Manager settings, because .htaccess begins with a dot and stays invisible by default.

Enabling and fixing the rewrite rules

Start inside WHMCS. Navigate to System Settings → General Settings → SEO and set Friendly URLs to the mod_rewrite option, then save. Before this works, the rewrite file must exist. Open File Manager, go to the folder that contains WHMCS index.php, and look for .htaccess.txt. Rename it to .htaccess using the Rename action. If an .htaccess already exists from another purpose, merge the rules rather than overwriting.

For a WHMCS install in the document root, the working block looks like this:

RewriteEngine On
RewriteBase /

# Send everything that is not a real file or directory to index.php
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?rp=/$1 [L,QSA]

If WHMCS lives in a subdirectory, the RewriteBase must reflect it exactly. For an install at public_html/billing/, use:

RewriteEngine On
RewriteBase /billing/

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?rp=/$1 [L,QSA]

The !-f and !-d conditions are what prevent an infinite loop and keep real assets, such as images and the admin folder, loading directly. The QSA flag preserves any query string a client already carries, which matters for affiliate and payment-return links. After saving, clear the WHMCS template cache by visiting Utilities → System → System Cleanup or simply deleting the contents of the templates_c/ folder through File Manager, then reload a product URL to confirm it resolves.

If paths still 404, check for two things. First, confirm the file is named exactly .htaccess with no trailing extension and no leading space. Second, look at the local error output. WHMCS writes to an error_log in the installation directory, and PHP errors can surface there through the File Manager without any SSH access. A 500 error immediately after adding rules usually means a duplicated RewriteEngine directive or an Options line the account disallows; removing any Options +FollowSymLinks line often clears it on managed accounts.

Canonical redirects, www, and HTTPS consistency

Search engines treat http://, https://, www, and non-www as separate addresses. If WHMCS is reachable on more than one of them, you split link equity and risk mixed-content warnings on payment pages. WHMCS itself has a canonical anchor: the WHMCS System URL under System Settings → General → General. Set this to the single, exact, HTTPS form you want, for example https://billing.example.com, with no trailing slash. Every internal link WHMCS generates flows from this value, so getting it right removes most inconsistency at the source.

Enforce that choice at the server level with redirect rules placed above the WHMCS rewrite block in the same .htaccess. To force HTTPS and drop the www prefix:

RewriteEngine On

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

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

Use %{HTTP_HOST} as shown rather than hardcoding a domain, so the same file survives a domain change. Behind LiteSpeed with a shared SSL terminator, the %{HTTPS} variable is reliable, so proxy detection tricks used on other stacks are generally unnecessary. If you also run other applications and need a deeper look at HTTPS behaviour behind a proxy, the patterns in our Nextcloud SSL and HTTPS guide translate well. Keep in mind that 301 redirects are cached hard by browsers; test in a private window after each change so you are not chasing a stale redirect that was already fixed.

Confirm the certificate covers your exact hostname first. In cPanel → SSL/TLS Status or DirectAdmin's SSL Certificates panel, an AutoSSL entry must exist for the hostname in your System URL, otherwise the forced-HTTPS rule sends visitors to an untrusted-certificate warning.

Sitemaps, indexing, and graceful 404s

WHMCS does not auto-generate an XML sitemap the way a blog CMS does, because most of the client area sits behind login and should not be indexed. The pages worth exposing are public product/store pages, announcements, and knowledgebase articles. Build a small static sitemap listing those canonical URLs, upload it as sitemap.xml into the WHMCS root through File Manager, and submit it in Google Search Console. Point search engines at it and keep private paths out with a robots.txt in the same directory:

User-agent: *
Disallow: /clientarea.php
Disallow: /cart.php?a=view
Disallow: /dl.php
Disallow: /admin/
Allow: /

Sitemap: https://billing.example.com/sitemap.xml

For genuine dead links, let WHMCS handle the response rather than the raw server. When mod_rewrite friendly URLs are active, unmatched knowledgebase or announcement IDs route through index.php and WHMCS returns its own styled not-found page with a proper 404 status, keeping the branding intact. For requests that miss the application entirely, add an ErrorDocument line near the top of .htaccess so visitors see a controlled page instead of a bare server error: ErrorDocument 404 /index.php. Verify the returned status code with your browser's Network tab; a page that looks like a 404 but returns HTTP 200 (a soft 404) will keep dead URLs in the search index.

After any change to friendly URLs, regenerate links by clearing templates_c/ and revisit a handful of real product, cart, and knowledgebase paths. Watching the installation's error_log in File Manager while you test turns invisible rewrite failures into readable messages, which is the fastest way to close out the last stubborn 404 without ever needing shell access.