Description
Gozer makes your entire WordPress site private by requiring visitors to log in before they can see any content. Perfect for intranets, membership sites, development environments, or any site that needs restricted access.
Unlike other force login plugins, Gozer gives you complete control over exceptions. Configure exactly what should remain publicly accessible through an intuitive settings page.
Key Features
- One-click activation – Enable force login with a single checkbox
- Admin bar toggle – Quick on/off switch directly from the toolbar
- System exceptions – Keep REST API, WP-Cron, WP-CLI, and AJAX working
- SEO-friendly – Allow search engine bots, sitemaps, and robots.txt
- Custom paths – Define specific pages that should remain public
- Advanced IP whitelist – Supports individual IPs, CIDR notation, and wildcards
- Temporary bypass tokens – Generate shareable links for temporary access
- User agent rules – Grant access to monitoring services
- Flexible redirects – Choose login page, 403 error, or custom URL
- Lightweight – No bloat, just the features you need
IP Whitelist Formats
The plugin supports multiple IP formats:
- Individual IPs:
192.168.1.1 - CIDR notation:
192.168.1.0/24or10.0.0.0/8 - Wildcards:
192.168.*or10.*.*.*
Temporary Bypass Tokens
Generate secure, time-limited access links perfect for:
- Client reviews of staging sites
- Sharing with contractors or agencies
- Temporary access for support teams
- Preview links for stakeholders
Use Cases
- Private company intranets
- Client staging sites
- Membership communities
- Development and testing environments
- Employee portals
- Educational platforms
Support
Need help or have suggestions?
Love the plugin? Please leave us a 5-star review and help spread the word!
About AyudaWP
We are specialists in WordPress security, SEO, and performance optimization plugins. We create tools that solve real problems for WordPress site owners while maintaining the highest coding standards and accessibility requirements.
Screenshots
Installation
- Upload the
gozerfolder to/wp-content/plugins/ - Activate the plugin through the ‘Plugins’ menu in WordPress
- Go to Settings > Gozer to configure options
- Enable the “Require login to access the site” checkbox
- Configure exceptions as needed
FAQ
-
Will this break my site?
-
The plugin is designed with safe defaults. Critical functionality like REST API, WP-Cron, and AJAX are allowed by default to prevent breaking the block editor or scheduled tasks.
-
Can search engines still index my site?
-
Yes, if you enable the “Allow search engine crawlers” option. Major search engine bots (Google, Bing, etc.) will be able to access and index your content.
-
How do I allow specific pages to be public?
-
Go to Settings > Gozer and add paths to the “Allowed paths” field. Enter one path per line, like
/contact/or/about/. -
How do I whitelist an entire IP range?
-
Use CIDR notation (e.g.,
192.168.1.0/24for a /24 subnet) or wildcards (e.g.,192.168.*for all IPs starting with 192.168). -
How do bypass tokens work?
-
Generate a token in Settings > Gozer, then share the generated URL. Anyone with that link can access the site without logging in until the token expires.
-
Can I use it on a multisite network?
-
Yes, the plugin works on multisite installations. Each site can have its own configuration.
-
Why “Gozer”?
-
Gozer the Gozerian is the supernatural entity from Ghostbusters (1984) who asked “Are you a god?” before denying access to mere mortals. Just like our plugin does with your site visitors.
-
Why can a logged-in user still not see my site?
-
If you set a “Minimum access level” higher than the user’s role, logged-in users below that level are treated like logged-out visitors and shown a 403 page. This front-end restriction is independent from the WordPress dashboard: a Subscriber can still reach their profile screen but will not see the front-end. Set the access level back to “Any logged-in user” to allow every logged-in user through.
-
I enabled private mode but old pages still load without logging in
-
A page cache (a caching plugin, your host, or a CDN) can serve pre-generated HTML without running WordPress, so Gozer never sees those requests. Gozer purges the major caching plugins automatically when you activate the plugin, toggle private mode, or save settings, but if your host or CDN caches HTML you may need to purge it once after enabling Gozer.
Reviews
Contributors & Developers
“Force login to make the site private – Gozer” is open source software. The following people have contributed to this plugin.
Contributors
“Force login to make the site private – Gozer” has been translated into 2 locales. Thank you to the translators for their contributions.
Translate “Force login to make the site private – Gozer” into your language.
Interested in development?
Browse the code, check out the SVN repository, or subscribe to the development log by RSS.
Changelog
2.0.0
- New: Minimum access level. Require a minimum role (Subscriber, Contributor, Author, Editor, or Administrator) for logged-in users to view the front-end. Lower-privileged users are shown a 403 page instead of the content, so an intranet can keep subscribers out while letting editors in. The front-end access level is independent from WordPress dashboard capabilities.
- New: Custom 403 block screen. Set your own title and message (basic HTML allowed) for the 403 mode without editing your theme. A theme 403.php template still takes precedence if present.
- Improved: Page cache hardening. When a visitor is blocked, Gozer now sets DONOTCACHEPAGE and sends no-cache headers on every block path (login redirect, custom URL, and 403) so page caches and CDNs never serve the block response to the wrong visitor. Public exceptions stay fully cacheable, and known page caches are purged automatically when the plugin is activated or deactivated and when private mode or the settings change.
- Improved: The REST API, XML-RPC and AJAX system exceptions now take effect for logged-out visitors instead of being informational. With the site private and the exception off, /wp-json/ stops exposing your content to anonymous requests and XML-RPC is disabled; logged-in users and the IP, user-agent and bypass-token exceptions are always respected.
- Fix: An “Allowed paths” entry of “/” exposed the entire site instead of just the homepage it promises. It now matches the homepage only, on root and subdirectory installs alike.
- Fix: On subdirectory installs, the login redirect built the return URL with the site path doubled (e.g. /site/site/), landing visitors on a 404 after signing in.
- Fix: WordPress’ virtual robots.txt was blocked on sites using “plain” permalinks (served as /?robots=1) even with the robots exception enabled. Both the virtual and the physical robots.txt are now recognized.
- Fix: “Allowed paths” rules were ignored on subdirectory installs because the request path includes the subdirectory. Rules now also match with the install base prefixed, so “/contact/” matches “/site/contact/”.
- Fix: IP whitelist wildcards now work as documented. A pattern like 192.168.* matched no real address before (it expected a single octet); a trailing * now covers the rest of the address, so 192.168.* allows the whole 192.168.x.x range.
- Fix: The “Redirect to custom URL” option now works with external URLs. wp_safe_redirect only allowed the site’s own host, so an external address silently fell back to wp-admin; the configured host is now allowed.
For older changelog entries, please check the changelog.txt file