Prevent 404 Errors After Deactivating WP Ghost – Redirect Rules for Apache and Nginx
March 22, 2024
This tutorial has moved to the new WP Ghost Knowledge Base where each feature is presented in detail.
If you deactivate WP Ghost after using custom paths, Google and visitors may still request the old custom URLs. Add redirect rules in .htaccess (Apache) or nginx.conf (Nginx) to map the custom paths back to the original WordPress paths and prevent 404 errors.
Why 404 Errors Happen After Deactivating WP Ghost
When WP Ghost is active, it changes your WordPress paths to custom URLs. For example, /wp-content/ might become /core/, /wp-content/uploads/ might become /storage/, and /wp-content/themes/ might become /core/views/. These custom paths are the URLs that Google indexes, that visitors bookmark, and that other sites link to.
When you deactivate WP Ghost, the rewrite rules that map these custom paths to the actual WordPress directories are removed. The original /wp-content/ paths start working again, but the custom paths no longer resolve. Any request to /core/style.css or /storage/image.jpg now returns a 404 error because the server does not know where to send those URLs anymore.
This affects Google search results (which still index the custom URLs), cached pages in visitors’ browsers, CDN caches that stored the custom URLs, external links from other websites, and bookmarks saved by your users.
The solution is to add redirect rules that map your custom paths back to the original WordPress paths. These rules should stay in place until Google has re-indexed your site with the original URLs and all external caches have refreshed.
Before You Deactivate – Consider This First
If you are deactivating WP Ghost because of a configuration issue rather than permanently removing it, consider these alternatives first:
Use the Safe URL to temporarily disable path security without deactivating the plugin. This lets you fix settings while keeping the plugin active. See Disable WP Ghost in Case of Error.
Switch to Disable Mode in WP Ghost > Change Paths. This turns off all path changes while keeping the plugin installed, which preserves your configuration for later reactivation.
Use the 5-minute pause feature in WP Ghost > Change Paths for quick testing without permanent deactivation.
If you do need to fully deactivate and uninstall, follow the redirect rules below to prevent 404 errors.
Fix for Apache and LiteSpeed Servers
If your website runs on an Apache or LiteSpeed server, add redirect rules to the .htaccess file in your WordPress root directory.
1. Connect to your server using sFTP or your hosting File Manager.
2. Open the .htaccess file in your WordPress root directory.
3. Add the following rewrite rules at the beginning of the file, before the WordPress rewrite block:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^([_0-9a-zA-Z-]+/)?core/views/(.*) /wp-content/themes/$2 [QSA,L]
RewriteRule ^([_0-9a-zA-Z-]+/)?storage/(.*) /wp-content/uploads/$2 [QSA,L]
RewriteRule ^([_0-9a-zA-Z-]+/)?core/(.*) /wp-content/$2 [QSA,L]
RewriteRule ^([_0-9a-zA-Z-]+/)?lib/(.*) /wp-includes/$2 [QSA,L]
</IfModule>
4. Save the file and test your website. Try accessing URLs that use the old custom paths. They should now redirect to the correct WordPress paths instead of returning 404 errors.
Important: The example above uses the custom paths “core” (for wp-content), “core/views” (for themes), “storage” (for uploads), and “lib” (for wp-includes). If you used different custom names in WP Ghost, replace these with the actual custom paths you configured. Check your WP Ghost settings or your browser history to find the custom paths you were using.
Fix for Nginx Servers
If your website runs on Nginx, add redirect rules to your Nginx server configuration file.
1. Connect to your server via SSH.
2. Open your Nginx server block configuration file (typically at /etc/nginx/nginx.conf or in /etc/nginx/sites-available/).
3. Add the following rewrite rules inside the server block:
if (!-e $request_filename) {
rewrite ^/([_0-9a-zA-Z-]+/)?core/views/(.*) /wp-content/themes/$2 last;
rewrite ^/([_0-9a-zA-Z-]+/)?storage/(.*) /wp-content/uploads/$2 last;
rewrite ^/([_0-9a-zA-Z-]+/)?core/(.*) /wp-content/$2 last;
rewrite ^/([_0-9a-zA-Z-]+/)?lib/(.*) /wp-includes/$2 last;
}4. Save the file and reload Nginx:
sudo systemctl reload nginx
5. Test your site by accessing URLs with the old custom paths. They should now resolve correctly.
As with the Apache solution, replace the example custom paths with the ones you actually used in WP Ghost.
How Long to Keep the Redirect Rules
Keep the redirect rules in place until Google has fully re-indexed your site with the original WordPress URLs. This typically takes 2 to 4 weeks, but can take longer for larger sites. You can check the progress in Google Search Console by monitoring indexed pages and looking for crawl errors on the old custom URLs.
Once Google no longer references the old custom paths and your site traffic shows no 404 errors from those URLs, you can safely remove the redirect rules.
If other websites link to your site using the custom URLs, consider keeping the redirects permanently. Those external links will continue to generate 404 errors if the rules are removed, and updating links on other websites is often not possible.
How to Find Your Custom Paths
If you do not remember what custom paths you used, there are a few ways to find them:
Check Google Search Console. Go to Coverage (or Pages) and look for 404 errors. The URLs that return 404 will contain your old custom paths.
Check Google’s cache. Search for your site in Google and click the cached version of any page. View the source code and look for the asset URLs, those will show your custom paths.
Check your browser cache. If you recently visited your site while WP Ghost was active, your browser may still have cached pages. View source on a cached page to find the custom path names.
Check CDN cache. If you use a CDN like Cloudflare, check the cached assets. The URLs will contain your custom paths.
Frequently Asked Questions
Will deactivating WP Ghost automatically remove the custom paths?
Yes. When you deactivate WP Ghost, all rewrite rules are removed and the original WordPress paths become active again. The custom paths stop working immediately. This is by design: WP Ghost does not physically change any files, so deactivating the plugin restores everything to default. The problem is that external references (Google index, bookmarks, CDN cache) still point to the old custom URLs.
Do I need redirect rules if I only used Safe Mode?
Yes, if you used custom paths in Safe Mode and Google indexed those paths. Safe Mode and Ghost Mode both change URLs that get indexed by search engines. The redirect rules work the same way for both modes.
Can I just reactivate WP Ghost instead of adding redirect rules?
Yes, that is actually the simplest solution. If you reactivate WP Ghost with the same custom paths, everything works again immediately. The redirect rules in this tutorial are specifically for situations where you are permanently removing the plugin and need to handle the transition period.
Will this affect my SEO?
The redirect rules use internal rewrites (not 301 redirects), so the server serves the correct content at the custom URL without a visible redirect. This prevents 404 errors which would negatively impact SEO. Over time, as Google re-crawls your site, it will update its index to the original WordPress URLs. There may be a temporary ranking fluctuation during this transition period.
What if I used custom plugin and theme names too?
The redirect rules above handle the main directory paths (wp-content, wp-includes, themes, uploads). If you also customized individual plugin or theme folder names in WP Ghost, you will need additional rewrite rules for each one. For example, if you renamed the “contact-form-7” plugin to “forms”, add a rule that maps /core/extensions/forms/ to /wp-content/plugins/contact-form-7/.
Does WP Ghost modify WordPress core files?
No. WP Ghost uses server rewrite rules and WordPress hooks. No core files are moved, renamed, or modified. Deactivating the plugin restores all default paths instantly, which is exactly why the redirect rules in this tutorial are needed for the transition period.
