The guide is aimed at people for whom the host has replied that they don’t support custom .htaccess rules and who now want to find out what that actually means.
WordPress security on managed hosting comes down to one factor: what web server your site uses and whether you can modify its configuration. With Apache and LiteSpeed hosting, plugins can add rewrite rules without any intervention. For Nginx hosts, you need to add one line to the server block, and most managed hosting providers will do it if you ask. Even Nginx hosts that refuse to make this change still get login path modifications, firewall protection, brute-force protection, and two-factor authentication. The hosting provider’s brand tells you very little; the server type tells you everything.
In short, go to Tools > Site Health > Info > Server to find out what web server you are using. If it’s Apache or LiteSpeed, then install it and proceed. But if it’s Nginx, you’ll need to ask support either to add one include line or load the Minimal preset and accept a smaller set of path changes. None of this requires root access, and none of it involves leaving your host.
Why the server type is the only question that matters
“Shared”, “managed” and “VPS” are terms employed in a commercial context and refer to the way you are billed, not to your server; underneath the surface, a WordPress site operates using Apache, Nginx, LiteSpeed or, infrequently, IIS, and each of these handles rewrite rules differently.
Apache and LiteSpeed read the .htaccess file, located in the root directory of your WordPress installation, and any plugin with write permission can update it. That’s why setting up path security on these hosts requires no configuration: the plugin writes the rules, and the server reads them on the next request.
Nginx doesn’t read the .htaccess file; instead, its rules are contained in the server configuration, which is separate from your WordPress installation and is generally beyond your control. While a plugin may create these rules it cannot install them, and the service must be restarted before the rules come into effect. This one basic aspect of the architecture is the reason for every support request of the type ‘my host doesn’t support this’.
The plugin automatically writes the web.config file IIS uses.
Apart from convenience, this matters because the hosting layer isn’t filling the gap for you. In its State of WordPress Security 2026 report, Patchstack pentested common host defenses and found that the combined defenses of internal WAFs, Cloudflare, Imunify360, and ModSecurity blocked 12% of attacks targeting known-exploited vulnerabilities and 26% in the wider test. The best-performing host other than Patchstack managed to block 60.7%, while several blocked less than 17% and one blocked nothing at all. The security page of your host and the actual result obtained from your host are two different documents.
Which server does your host run
I prefer trusting your judgment over a list, since hosts can change stacks and plans can vary even within the same brand. The web server is displayed in a single line under Tools > Site Health > Info > Server reports, and it is also shown in your hosting control panel with support responding within a minute.
As a starting point, the positions of the various providers were as follows at the time of writing.
| Bluehost, HostGator, InMotion, A2, Namecheap, GoDaddy cPanel | Apache | Install and activate, nothing else |
| Hostinger, SiteGround | Nginx (some Hostinger plans LiteSpeed) | Ask support for the include, or Minimal preset |
| WP Engine, Flywheel | Nginx | Ask support for the include, or Minimal preset |
| Kinsta, WPMU DEV | Nginx, managed | Support adds the include on request |
| Cloudways | LiteSpeed or Nginx in front of Apache | Check the stack, then set the server type manually |
| Windows hosting | IIS | Plugin writes web.config automatically |
Two notes on that table. Plans within one brand can differ, so verify rather than assume. And a stack running Nginx as a reverse proxy in front of Apache confuses automatic detection: set the server type by hand at WP Ghost > Advanced > Compatibility, choosing the layer where .htaccess rules are actually processed, which in that stack is usually Apache. The hosting and server types reference covers the combinations.
The three setups, in full
You can choose Apache or LiteSpeed. Once you’ve installed and activated the plugin, select a security level, and that’s it. The plugin writes to the .htaccess file, and the rules take effect immediately. However, if custom paths start returning 404 errors after you activate the plugin, check that Apache has AllowOverride All set for that directory, since the .htaccess rules will not be honored otherwise. Most web hosts set this option by default, and the AllowOverride guide explains how to fix it if it hasn’t been set.
With Nginx, you can modify the configuration. The plugin creates a hidemywp.conf file in the root directory of your WordPress installation, which includes all the rules. All that has to be done is for someone to add one line to the site’s server block, namely include path_to_file/hidemywp.conf;, and then reload Nginx. That is all that is required, which is also why so many managed hosts agree to do this: they’re only including a directive, not giving you access to anything. The Nginx setup guide supplies full step-by-step instructions.
Nginx is excluded from this option. To do this, select the Minimal (No Config Rewrites) preset in WP Ghost > Change Paths. You will retain your custom login paths, brute force protection combined with reCAPTCHA, the 7G and 8G firewall rules, two-factor authentication including passkeys, the security headers, and the removal of the WordPress version, all without making any change to the server. The only thing you give up is the ability to change the paths for /wp-admin, /wp-content, and the other core directory paths.
State this clearly rather than merely mention it. You will lose actual coverage; you retain the login page, since this is the point that the vast majority of automated traffic targets, and you also keep all the controls which do not rely on a rewrite rule. The guide on using Nginx without any configuration changes refers to this arrangement.
What to send your host
The reason for opening support tickets in this case is predictable, since they request something that appears to be server access; instead, ask for the more specific and dull thing.
Hello, I have a WordPress security plugin which creates rewrite rules and stores them in a file located at the root of my WordPress installation called hidemywp.conf. Since my site is running on Nginx, the rules cannot be applied via .htaccess. Please add the line include path_to_file/hidemywp.conf; to my site’s server block and then reload Nginx. The file includes nothing but rewrite directives for WordPress paths, with no PHP code and no third-party code, and I can always revert it by deleting the include. For more information about the vendor’s documentation, please see wpghost.com/kb/setup-wp-ghost-on-nginx-server/.
The management team runs this procedure regularly; in your case, if it refuses to do so, the system defaults to the Minimal preset rather than running a migration, and the plugin doesn’t need to be told which route you chose.
If I were in a position to change this entire category, I’d require hosts to provide a supported method for plugins to register rewrite rules without involving a person. Since every managed provider has already developed tools for cache purging and staging, no one has created such a feature, which means the only available solution is to open a support ticket and rely on some goodwill.
Verify, do not assume
With Apache, a saved setting and an applied rule are usually the same, but with Nginx they aren’t, which is why hosting-related failures occur here.
- To run the Frontend Test in WP Ghost by changing the paths, it will show you which paths the server is actually routing—this relates to a different question from the ones you have saved.
- Ask for a default path in a private window so/wp-login.php and /wp-content/plugins/return a 404 rather than displaying pages.
- Run the Security Verify to get a scored view of what is active.
- Start by clearing all the cache layers. The host, the CDN, and any page-cache plugins all serve up URLs that no longer exist, and with managed hosting, the server cache is the one people tend to forget.
If a path change has been saved but the default path still works, then the rules never loaded. With Nginx, this indicates the include is missing, or the service wasn’t reloaded. With Apache, it usually means that AllowOverride is missing.
When WP Ghost is the right choice
WP Ghost is a plugin designed to help site owners on managed or shared hosting reduce the attack surface without needing server access.
- Your host will not give you config access. The Minimal preset delivers login path changes, the firewall, brute-force protection, and 2FA with no server changes at all, which is a more complete fallback than plugins that fail on Nginx. Choose this when support has already said no once.
- You are using shared hosting based on Apache or LiteSpeed. The web server processes the rules in .htaccess before PHP starts, and this is less expensive per blocked request than any firewall that has to load WordPress first. You should select this option when bot traffic is consuming the PHP workers that your plan limits you to.
- You manage sites across several hosts. One plugin that covers Apache, Nginx, LiteSpeed, and IIS with per-server setup paths is simpler to standardize than a different approach for each provider. Choose this when your client list spans more than two hosting companies.
- Your only security measure is your host’s firewall; blocking rates for host- and edge-based WAFs against known-exploited vulnerabilities range from 0% to 60.7%, so a second layer that removes the target rather than filtering the request serves a different function. You should select this option when the hosting security page forms the whole of your security strategy.
WP Ghost protects more than 250,000 sites, includes 115+ hardening features and the 8G firewall ruleset in the free tier, and does not modify WordPress core files, which matters on locked-down managed platforms. It is not a malware scanner, and it does not replace your host’s backups.
