How PeepSo Builds Its URLs

PeepSo is a WordPress plugin, not a standalone application, so every community URL it generates depends entirely on the WordPress permalink engine and the rewrite rules stored in your .htaccess file. When you activate PeepSo, it registers a set of virtual pages and endpoints under the profile page you assign during setup. A typical profile URL looks like https://example.com/profile/johndoe/, an activity stream sits at https://example.com/activity/, and group pages resolve to https://example.com/groups/team-alpha/. None of these paths correspond to real directories on disk. They are rewritten on the fly by WordPress using the rewrite rules it flushes into the database and the fallback directives LiteSpeed reads from .htaccess.

This architecture explains why the most common PeepSo URL complaint is a flood of 404 errors on profile, group, and activity pages while the homepage and standard posts load fine. The homepage works because the server finds index.php directly. The PeepSo pages fail because the rewrite layer that maps a pretty URL back to index.php?page_id=... is either missing, out of date, or being intercepted by a conflicting directive. On a fresh install this happens when WordPress is left on the default Plain permalink structure, which uses query strings like ?p=123 and never generates the pretty endpoints PeepSo expects.

LiteSpeed Web Server, which runs across Hostiso's AlmaLinux and CloudLinux stack, reads .htaccess natively and honors standard mod_rewrite syntax, so you do not need any special configuration to make rewrites work. What trips people up is that LiteSpeed also caches aggressively through LSCache. A cached 404 or a cached redirect can survive long after you have corrected the underlying rule, making it look as though your fix did nothing. Keeping the caching layer in mind while you troubleshoot saves a great deal of confusion. If you are also chasing fatal errors or white screens alongside URL faults, work through those first using our companion approach to friendly URLs and canonicals as a mental model, since the diagnostic order matters.

Start inside the WordPress dashboard rather than in files, because the cleanest fix regenerates the rewrite table for you. Log into wp-admin, open Settings → Permalinks, and confirm the structure is set to Post name or any option other than Plain. PeepSo requires a non-plain structure to produce clean profile and group slugs. Even if the setting already looks correct, click Save Changes at the bottom of the page. That single action forces WordPress to call flush_rewrite_rules(), rebuild the rule set, and rewrite the .htaccess block. A surprising number of PeepSo 404 problems vanish at this step alone, because the plugin's endpoints simply had not been registered after an update.

If pages still 404 after re-saving permalinks, open the cPanel File Manager (or DirectAdmin's equivalent under System Info & Files → File Manager), navigate to your document root at public_html, and enable Show Hidden Files (dotfiles) from the settings menu. Open .htaccess and confirm the standard WordPress block is intact and present exactly once:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Two mistakes dominate here. The first is a duplicated or malformed block left behind by a security plugin or a migration, which causes LiteSpeed to apply rules in the wrong order. Delete any extra rewrite blocks so only one remains. The second is an incorrect RewriteBase value when PeepSo runs in a subdirectory such as public_html/community. In that case both RewriteBase and the final RewriteRule target must point at the subfolder, for example RewriteBase /community/ and RewriteRule . /community/index.php [L]. Save the file, then purge LiteSpeed cache from the LiteSpeed Cache plugin's toolbar (Purge All) so a stale cached 404 does not mask your success. Test a profile and a group URL in a private browser window to bypass local browser caching.

If editing permalinks produces a blank or unwritable .htaccess, check the file permissions in File Manager. The file should be 644 and owned by your hosting user. A 444 or root-owned file prevents WordPress from updating it, so you would need to paste the block manually and set permissions back to 644.

Canonical Redirects and HTTPS Consistency

Search engines treat http versus https and www versus non-www as distinct URLs, and PeepSo activity feeds generate a large number of internal links that inherit whatever base URL WordPress reports. If that base is inconsistent, you get duplicate content, split ranking signals, and mixed-content warnings on profile pages that load avatars over the wrong protocol. Set the single canonical form under Settings → General by making WordPress Address (URL) and Site Address (URL) identical, including the protocol and the exact www choice you intend to keep.

Enforce that choice at the server edge with a rewrite rule placed above the # BEGIN WordPress marker in .htaccess, so it runs before WordPress processes anything. To force HTTPS and strip www:

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

The NE flag is important for PeepSo because profile and search URLs can contain encoded characters, and without it a 301 can corrupt query strings. Use a 301 rather than a temporary 302 so search engines consolidate authority onto the canonical version. After deploying, purge LSCache again and verify with a command-free check: open the non-canonical variant in a browser and confirm it lands on the canonical one. If you prefer the AutoSSL certificate Hostiso issues to cover both hostnames, make sure both the bare domain and the www entry appear in cPanel → SSL/TLS Status before enforcing HTTPS, otherwise the redirect could point visitors at an uncovered hostname and trigger certificate warnings.

Sitemaps, Indexing, and 404 Cleanup

PeepSo community pages are virtual, so they do not automatically appear in an XML sitemap the way standard posts do. If you run an SEO plugin such as Yoast or Rank Math, open its sitemap settings and decide deliberately which PeepSo content types to expose. Public group pages can be valuable for discovery, but individual member profile pages are usually thin, duplicative, and better left out of the sitemap to avoid diluting crawl budget. In Yoast, visit Yoast SEO → Settings → Content types and toggle the Show in search results option for the relevant PeepSo post types; a setting of No adds a noindex directive and keeps that type out of the generated sitemap at https://example.com/sitemap_index.xml.

For activity streams and search result pages, add a targeted exclusion so crawlers do not waste requests on infinitely paginated feeds. A clean approach is to noindex the activity endpoint through your SEO plugin's advanced per-page controls rather than blocking it in robots.txt, because blocking the URL prevents search engines from reading the noindex tag at all. Reserve robots.txt (editable as a plain file in public_html) for genuinely private areas, and keep your sitemap reference line intact so crawlers can still find it:

Sitemap: https://example.com/sitemap_index.xml

When legitimate pages have moved after a slug change in PeepSo settings, old links will 404. Rather than leaving them broken, add explicit redirects near the top of .htaccess so link equity carries forward, for example RewriteRule ^members/([^/]+)/?$ /profile/$1/ [R=301,L] if you renamed the profile base from members to profile. Confirm each rule works before adding the next, and remember that LiteSpeed may cache a 301 for a long time, so purge after every change. Finally, review your account's error_log inside the PeepSo directory and in public_html through File Manager; a repeating File does not exist entry for a specific endpoint points straight at a missing rewrite rule, while a pattern of requests to ?page_id= URLs usually means the permalink structure quietly reverted to Plain after an update and simply needs re-saving.