Nindohost or xneelo: which WordPress hosting for a cached members' area?

One public cache, two accounts to keep separate

An association publishes news and open resources in WordPress. It also provides an area where each member sees their own profile and documents. The team wants to reduce the computation needed to display news without the cache sharing a personalised response. This scenario concerns HTML page caching and endpoints returning the same type of data within a single WordPress installation. It compares neither membership-plugin features nor raw server performance.

The risk arises when a layer in front of WordPress reuses a response body generated for a different session. For example, the first member opens their profile; if the cache relies only on the address and retains that response, the next member may receive the first member's content before WordPress even checks permissions. A correct screen on the first load is therefore insufficient. Visit order and cache state are part of the test.

The two plans examined are Nindohost Plus Site in Morocco and xneelo Web Hosting Basic in South Africa. To distinguish the offerings, ask who can exclude the member page and its associated routes, how to confirm that they reach WordPress and who can disable the cache in an emergency. An offering may suit the project while leaving the private area entirely dynamic, even if public-page caching is limited to a few addresses.

Reserve shared caching for public responses

First list routes according to what they return. A news item identical for every anonymous visitor can be cached. Login, logout, password reset, the dashboard and protected documents must be examined separately. Add plugin routes that return profile data, including JSON calls visible in the Network tab. A public menu may load a personalised block after the page renders; caching of that second call must also be checked.

For the first deployment, start with a simple rule: retain only anonymous public responses, avoid page caching for every logged-in session and exclude sensitive URLs. If the application produces a private response, enforce its cache directives at every layer. A path-based exclusion must cover its actual variants, including the exact path, subpages and the parameter-based access mode used by the plugin.

Also check WordPress-side permissions with an anonymous visitor, a member and an unauthorised account. A cache exclusion adds no access control. If a document can be opened anonymously through its file address, first correct the resource's protection. Likewise, HTML rendering that hides a button does not prove that the API and download address are protected.

Reproduce the risk with a few local requests

The ZIP file contains a dependency-free Node.js mock-up, instructions and the expected result. The command starts a server on the loopback interface, generates fictional responses and stops it at the end. It simulates two members, Alice and Boris, an anonymous visitor, a public page and private routes. The markers are invented for the acceptance test. The script does not install WordPress, contact the hosts or send any production data.

The first sequence deliberately creates an incorrect cache that stores GET responses by path alone, even when they are private. After Alice visits, Boris and the visitor receive Alice's marker on the same route. This negative case verifies that the protocol detects the leak; it does not reproduce a Nindohost or xneelo configuration. A second sequence starts with an empty cache and applies restrictive conditions before cache reads and writes.

The corrected sequence requests the public news item twice without a session and verifies that it is actually reused. It then requests both members' profiles and tests anonymous access. It also verifies that a visitor does not receive the members-only JSON response and that a response containing a session cookie is not stored. The MISS, HIT and BYPASS indicators belong to the mock-up. On a real site, their equivalents depend on the active layer.

• Download the “Local cache exercise for members” ZIP in “Further reading”, then extract it and run node recette.mjs from the resulting folder.
• Compare the results with attendu.json. The demonstration must detect the leak in incorrect mode and verify isolation in corrected mode.

What the difference between the two sequences shows

The faulty cache returns two responses that should never have left Alice's session. For Boris and the visitor without a cookie, the content still carries FICHE-ALICE while also carrying a private-response directive. This illustrates the danger of a misconfigured layer ignoring application instructions. Status 200 alone signals nothing unusual to Boris. You must check the response body and, if possible, identify which layer served it.

In corrected mode, the second anonymous news request receives a HIT. A logged-in request, even to that same address, passes through without reusing the anonymous copy. Profile requests receive two different bodies; the anonymous visitor is denied access to both the profile and API. A public address with a parameter bypasses the mock-up's cache to avoid introducing an ambiguous cache key. This conservative choice does not set the policy for every parameterised URL on a real site.

The test also checks a response that sets a cookie while declaring itself public. In the mock-up, it is not stored, and a second request again receives its own response. A login submission is also processed outside the cache. The check concerns these HTTP responses and their markers, without timing measurements. It verifies neither real WordPress authentication, a membership plugin nor a CDN.

Nindohost Plus Site: define LiteSpeed's scope in WordPress

The Plus Site page advertises cPanel and LiteSpeed with LSCache. LiteSpeed's documentation describes a setting for privately caching pages for logged-in users. For this scenario, the team chooses not to use that feature in the first deployment: logged-in pages remain dynamic until rules and permissions have been proven on the copy. This decision alone does not disable another cache installed in front of the site.

On a private copy, open LiteSpeed Cache, then Cache and the Cache tab. Verify that page caching works before drawing conclusions about its scope. Set Cache Logged-in Users to OFF. In the Excludes tab, use Do Not Cache URIs for paths actually present, for example a rule beginning with ^/membres/ if that family exists, and a separate rule for the address without a trailing slash if it serves content. Add plugin routes, private downloads and variants that do not redirect. Do not reuse example URLs without examining the site.

If the membership plugin uses its own session cookie, identify its name on the copy and apply the Do Not Cache Cookies exclusion when the workflow requires it. Check that no rule forces inclusion of private URLs. Purge the plugin's page cache through its toolbox, then run acceptance checks while alternating sessions. The expected result is a cache indicator on an anonymous public page and no reused personalised body. If the layer is unavailable or labels differ, stop activation and identify the component actually supplied.

xneelo Basic: start with the layer the team controls

Basic is a WordPress-compatible Web Hosting plan. The help centre distinguishes using a WordPress plugin from Site Cache, the Web Accelerator proxy. Its activation guide sets Standard as the first eligible Web Hosting tier. The release covers selected accounts and plans hosted in South Africa. It does not cover plans hosted in Germany. Request confirmation of access for the proposed plan and hosting location before changing plans. Basic's price therefore covers using a WordPress cache plugin or no page cache; xneelo's proxy must not be counted as included.

On Basic, one option to test within WordPress is WP Super Cache, mentioned in xneelo's help. On a copy, open Settings, then WP Super Cache. Use simple mode and the option that excludes known users. In advanced settings, enter URL strings to exclude according to the installed version's menu; verify that membership paths and API routes are actually excluded. Confirm that no other page-cache layer bypasses these settings. The built-in homepage test checks reuse of a public page; add your own two-account tests.

If you are considering Standard and Site Cache is available in the account, identify its status in the Web Hosting panel, on the domain and under Web Accelerator. xneelo's help requires removing existing page-cache plugins before activation and indicates a recommended Varnish plugin. On staging, check how this setup handles routes, cookies and private responses. For this portal, keep the proxy disabled until its URL, session and private-response exclusions are established and a return to the origin server is prepared. If you cannot prove separation, keep the site dynamic while clarifying settings.

Compare amounts without inventing a renewal price

The November 10, 2026 observation shows Plus Site at a displayed MAD 79 per month, with MAD 119 crossed out and an introductory label. These two amounts establish neither the discount's duration nor the price at the next renewal. The billed cycle and tax basis are not established on the card. The terms describe a renewal pro forma generated fifteen days before the due date; this information does not turn the crossed-out reference into a renewal price.

xneelo Basic shows ZAR 99 per month, including VAT at public rates. Documentation for payments from a bank account outside South Africa provides for annual payment. Twelve times the public price gives a reference of ZAR 1,188 for Basic. Standard is listed at ZAR 149, or ZAR 1,788 over twelve months at a constant rate, excluding the domain. Site Cache is advertised at no extra charge during limited release for eligible accounts. Ask whether you have access and what price will apply after that phase. The table shows no separate introductory price for these tiers. The terms allow rates to change; renewal is therefore not guaranteed at these amounts.

To compare budgets, request both renewal amounts for the same scope: hosting, any cache layer, domain and taxes. Do not rank amounts denominated in MAD and ZAR solely by their numerical value. If your team must budget in another currency, record the rate actually offered by its payment method and fees at decision time. No payment, cart or currency exchange was checked here.

Repeat the acceptance test on a copy of your portal

Prepare two fictional users with the same member role and different profile data, then a session without a login. The same role makes the test more demanding: a role-shared cache must not be sufficient to distinguish their individual profiles. Use separate browser profiles. Multiple private windows in the same browser may share cookies. Place a distinct, harmless marker in each profile and in the API response if your portal uses one.

Start with caching disabled to prove that access behaves as expected. Then enable a single page-cache layer on the copy and purge it. Without logging in, load the same news page twice, then open the identical profile URL with Alice, Boris and the visitor, in that order. Purge and repeat with the two members reversed. Check redirects, the page after logout and private resources opened through a direct link. Record the expected result for each step, including denial for the visitor.

In the browser's network tools, record the status, displayed response, cache directives and indicators specific to the active layer. Do not include cookies, tokens or private bodies in the report; record only the presence of a fictional marker. If testing a CDN in front of the server, repeat from the copy's public address. Success observed by accessing the origin directly does not prove separation when the proxy is in the path.

Retain a quick rollback and choose the right plan

At the first response belonging to another session, stop the test. Disable the relevant page-cache layer and purge responses already generated from layers that could still serve them. For LiteSpeed, the documentation states that disabling Enable Cache stops page caching and clears its copies. For WP Super Cache, disable caching in its settings and clear cached files through the interface without deleting content files. Then repeat the profile and private-link checks without caching.

If you enabled xneelo's proxy on another tier, the guide describes removal under Web Hosting, the domain, then Web Accelerator and Site Cache. Prepare the origin destination and rollback DNS settings in advance. When xneelo manages the zone, its guide says removal redirects records to the server; if the zone is elsewhere, its administrator must point the site's records to the origin server before disabling the proxy, according to xneelo's guide. Check HTTPS and both accounts' responses after propagation. Advertised support guarantees neither configuration of a third-party plugin nor a recovery time.

Plus Site is the option to examine if the team wants to control LSCache from WordPress and obtain the billing cycle and renewal price in writing. Basic is an option if it prefers testing page caching in WordPress without paying for a proxy tier. If no layer can reproduce isolation, keep membership responses dynamic and return to public caching only when acceptance checks pass. For this portal, a lower price or faster public page does not replace session separation.

Further reading

• Read the Nindohost profile
• Read the xneelo profile
• Identify the cache layer serving an old response
• Local cache exercise for members (ZIP)