How UNA routes URLs and why rewrites break

UNA is a modular community platform where nearly every request passes through a single front controller. When you browse to a timeline, profile, or page, the web server is not loading a real file at that path. Instead, the request is rewritten internally to a dispatcher script such as index.php or a module handler, which then parses the remaining path segments and decides which module and template to render. This is the mechanism behind "friendly" URLs like https://example.com/page/timeline instead of the raw query-string form https://example.com/index.php?r=page/timeline.

The translation from a clean path to the dispatcher depends on mod_rewrite directives living in the .htaccess file at your document root (typically /home/USER/public_html/.htaccess). On the LiteSpeed Web Server that powers Hostiso shared accounts, these Apache-style rules are read natively, so no server reload is required. The breakage you usually see follows a predictable pattern: friendly URLs get enabled inside UNA, but the .htaccess rules that make them work are missing, overwritten by a migration, or placed in the wrong directory. The home page still loads because it maps directly to index.php, yet every deep link returns a 404 generated by the server rather than by UNA itself.

A second common cause is a path mismatch between where UNA thinks it lives and where it physically sits. If UNA was installed in a subfolder such as /home/USER/public_html/social/ and later moved, or if the site URL stored in the database no longer matches the real domain, the rewrite base becomes incorrect. The rules then rewrite to a directory that does not resolve, producing redirect loops or blank responses. Because you operate as an unprivileged hosting user, the fix never touches Apache or LiteSpeed configuration at the server level; everything is corrected through the UNA Studio dashboard, cPanel File Manager, and the per-account .htaccess file.

Repairing the .htaccess rewrite block

Start by confirming which URL mode UNA is using. Log into the dashboard at /studio/, open Settings → Permalinks (also exposed under Studio → Dashboard → Settings depending on your version), and note whether "Use friendly URLs" or the SEO links option is active. If it is on but deep links 404, the rewrite rules are the suspect. Leave the setting enabled for now and move to the file layer.

Open cPanel → File Manager, click the gear icon in the top right, and tick Show Hidden Files (dotfiles) so that .htaccess becomes visible. Navigate to your UNA document root. UNA ships a reference rewrite file; if yours is missing or has been flattened, rebuild the core block. A working minimal configuration for an install at the domain root looks like this:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    # Serve real files and directories untouched
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]

    # Route everything else through the front controller
    RewriteRule ^(.*)$ index.php?_q=$1 [QSA,L]
</IfModule>

The order matters. The first RewriteRule short-circuits requests for assets that exist on disk (CSS, images, uploaded media) so they are delivered directly and never passed to PHP. Only requests that do not map to a real file or folder reach index.php. If UNA lives in a subdirectory, set RewriteBase /social/ and adjust the rewrite target to social/index.php, or better, place a dedicated .htaccess inside that subfolder with its own base. After saving, use File Manager's right-click Edit to verify there are no stray smart quotes or a UTF-8 byte-order mark; LiteSpeed will silently ignore a corrupted directive and leave you chasing the wrong problem.

Test with a fresh incognito window so cached 301s do not mislead you. If deep links now resolve, the rewrite layer is healthy. If you still see server 404s, confirm mod_rewrite is being honored by temporarily adding a deliberate syntax error inside the IfModule block; if the whole site throws a 500, the file is being read, which narrows the fault to your rules rather than a disabled engine.

Canonical redirects and killing duplicate URLs

Search engines treat http vs https, www vs non-www, and trailing-slash variants as distinct URLs. UNA will happily render the same timeline under several of these, which dilutes ranking signals and can trigger duplicate-content warnings. The authoritative fix is to pick one canonical host and force every other variant to redirect to it with a 301.

First set the canonical host inside UNA so generated links and the <link rel="canonical"> tags match your choice. In Studio → Settings, confirm the site URL field uses the exact scheme and host you intend, for example https://example.com with no trailing slash and no www. Then enforce it at the edge in .htaccess, placing this block above the front-controller rules:

# Force HTTPS and strip www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

On Hostiso's managed stack, TLS may terminate at a proxy layer, so a naive %{HTTPS} check can loop. If you hit a redirect loop, swap the HTTPS condition for the forwarded header: RewriteCond %{HTTP:X-Forwarded-Proto} !https. Keep the redirect logic consistent with whatever your SSL setup expects; the companion article on UNA HTTPS and proxy awareness covers that detection in depth. Only edit one canonical rule set and test immediately, because stacked or conflicting redirect rules are the usual source of the "too many redirects" browser error.

For stubborn duplicate paths that UNA itself emits, avoid hand-coding per-URL redirects. Instead correct the source in Studio and let the canonical tag plus the single host-level 301 do the consolidation. Verify the result with the browser developer tools Network tab: a correct canonical request shows exactly one 301 hop, then a 200, with the Location header pointing at your chosen host.

Sitemaps, 404 handling, and verification

UNA generates an XML sitemap through its SEO module. In Studio, open the SEO or Permalinks module and enable sitemap generation; the feed is typically served at https://example.com/sitemap.xml, which is itself a rewritten virtual path, not a static file. Because generation runs on a periodic job, confirm that UNA's cron entry is active in cPanel → Cron Jobs, since without it the sitemap and other scheduled tasks never refresh. Once the feed returns content, submit that URL in Google Search Console and Bing Webmaster Tools, and reference it with a Sitemap: line inside /robots.txt so crawlers discover it automatically.

Handle 404s deliberately so that genuinely missing pages return a real 404 status and not a soft 200 or a redirect to the home page. Let UNA's own router produce the not-found page, and reserve ErrorDocument only for cases where PHP cannot run at all. A safe directive is ErrorDocument 404 /index.php?_q=404, but test it: a frequent mistake is pointing the error document at a path that triggers another rewrite, masking the status code. Use the Network tab or a header-checking request to confirm the response is HTTP 404, because incorrect status codes let search engines index empty pages.

When something still misbehaves, read the evidence rather than guessing. Rewrite and PHP faults surface in the per-account error_log files written alongside your scripts and in cPanel → Errors / Metrics → Errors. A 500 after an .htaccess edit almost always means a malformed directive; comment the suspect line with a leading # and reload. Clear UNA's template and route caches from Studio → Dashboard → Caches after any URL change, since cached links can keep serving the old pattern and make a correct fix look broken. Working methodically from the dashboard setting, down to .htaccess, and finally to the logs keeps every change inside your hosting account and reversible.