Intranet & Private Site - All-In-One Intranet

Install and activate the plugin, then go to Settings > All-In-One Intranet and check "Force site to be entirely private." All pages, posts, and custom content types will require login. The REST API and XML-RPC are also locked down automatically.

No. Media files (images, PDFs, videos, etc.) that are uploaded through WordPress remain accessible to anyone who knows the direct URL. This is because WordPress serves media files directly through your web server, bypassing PHP and plugin logic. This limitation is common to most WordPress privacy plugins. If direct media file protection is a requirement, you would need a server-level solution or a dedicated download protection plugin in addition to All-In-One Intranet.

Yes. When the private site option is enabled, unauthenticated REST API requests receive a 401 error response. This prevents external tools, scripts, or bots from accessing your content through API endpoints like /wp-json/wp/v2/posts. Authenticated requests from logged-in users continue to work normally. Two narrow sets of routes are exempt, and only while the plugin providing them is active: the endpoints two-factor and passkey plugins use to finish a login, and a site management platform's own API namespace for a request presenting that platform's credentials. See "For Developers" in the Description tab for how to adjust either list.

The plugin records a timestamp on the browser session each time a logged-in user loads a page. On the next page load, it compares the current time against that session's timestamp. If the difference exceeds the configured idle time, the user is logged out immediately. The idle timer resets on every page load, so users who are actively browsing are never interrupted, and each browser session keeps its own timer, so staying signed in at your desk does not keep a forgotten login on a shared machine alive. You can set the timeout in minutes, hours, or days. Only browser sessions are subject to it. A request that authenticates without a login cookie (a site management dashboard using its own API, or a script using an application password) has no session to expire, so it is left running and it does not reset anybody's idle timer.

Yes. In the Login Redirect section of the plugin settings, enter the full URL of the page you want users to land on after logging in. This overrides the default WordPress behavior of sending users to the dashboard. If a user was trying to reach a specific page before being asked to log in, they will be redirected back to that page instead of the custom redirect URL.

Yes. The plugin is fully compatible with WordPress multisite. In a multisite network, the settings are managed from the Network Admin area. You can make the entire network private, require users to be members of individual sub-sites before accessing them, and automatically assign roles to users across sub-sites when new users or new sites are created.

Yes, but it requires a small amount of code. Use the aioi_allow_public_access filter in your theme's functions.php file or a custom plugin. For example, to keep a page with the slug "public-info" accessible without login: add_filter( 'aioi_allow_public_access', function( $allow ) { if ( is_page( 'public-landing' ) ) { return true; } return $allow; } );

Yes. When the private site option is enabled, the plugin overrides the robots.txt file to disallow all crawling. It also disables outgoing pingbacks and trackbacks, so your site does not announce new content to external services or ping aggregators.

Generally, yes. Most WordPress caching plugins bypass the cache for logged-in users and do not cache redirects, so the privacy enforcement works as expected. However, aggressive full-page caching at the server level (Varnish, Nginx FastCGI cache) may serve cached pages to unauthenticated users if not configured to respect WordPress login cookies. If you use server-level caching, make sure it bypasses the cache when WordPress login cookies are absent.

On a single-site WordPress installation, users who are logged in but have no assigned role are treated as unauthorized. The plugin logs them out and displays a message explaining that they do not have permission to access the site. This prevents access by accounts that have been deactivated by removing their role rather than deleting them.

Yes. When the private site option is active, the plugin completely disables XML-RPC. This prevents any remote access through the XML-RPC protocol, including third-party apps and services that use it to interact with WordPress.

The plugin uses WordPress's built-in auth_redirect() function to send unauthenticated users to the login page. Most custom login page plugins work by intercepting the standard login URL and redirecting to a custom page. Because All-In-One Intranet relies on standard WordPress authentication functions, it is generally compatible with custom login page plugins. The login redirect feature also works regardless of whether the user logs in through the default or a custom login page.

Yes. Some 2FA plugins complete part of the login exchange with a background request from the login screen, which happens before the visitor is logged in. The plugin recognizes those requests and lets them through, so the second-factor prompt appears and login can finish. Wordfence, WP 2FA, miniOrange 2-Factor, Solid Security, AIO Login, Limit Login Attempts Reloaded and Login With Ajax passkey login are covered out of the box. Login With Ajax's own AJAX login form is not: that form lives on a front-end page, which is behind the login wall on a private site anyway. Plugins that keep the whole flow on the login page itself, such as Two-Factor, CleanTalk Security and Google Authenticator, need nothing special. Account recovery links are treated differently from login. A link that switches off a user's second factor is not needed to finish a login, so it stays behind the login wall even when the rest of that plugin is supported. miniOrange's emailed 2FA reset link is the current example. Ask an administrator to clear the second factor, or open that one endpoint yourself with the aioi_allow_public_access filter. Shield Security is the exception: its 2FA step shares one general-purpose endpoint with the rest of the plugin, so opening it would also open everything else behind that endpoint. If you use Shield's 2FA on a private site, add shield_action yourself with the aioi_public_actions filter described in the Description tab. If any other 2FA plugin reports a generic authentication error at login on a private site, its background request is being sent to the login wall. Developers can allow it with the aioi_public_actions or aioi_public_rest_routes filter, also in the Description tab.

Yes, all five, on a private site, with nothing to configure: ManageWP Worker (the same connector GoDaddy Pro uses), MainWP Child, InfiniteWP Client, WP Umbrella and WP Remote. Their dashboard requests are signed with their own keys instead of relying on a browser login, so site syncing, plugin and theme updates, backups, and the dashboard's one-click login into wp-admin keep working with "Force site to be entirely private" enabled. ManageWP, MainWP and InfiniteWP answer their dashboards from their own hooks before the privacy gate runs, so they need no exemption at all. WP Umbrella works through the WordPress REST API and WP Remote routes part of its traffic through admin-ajax.php, both of which a private site closes to unauthenticated callers, so each gets one narrow exemption while its plugin is installed. Neither is a blanket hole: WP Umbrella's namespace opens only for a request that presents its credentials, and WP Remote's action only once WP Remote has verified the caller's signature itself. An anonymous request to either endpoint is still sent to the login wall, and a credentialed one still has to pass the platform's own checks. The exemption hands the decision to the platform rather than removing it. Auto-logout understands these requests as well. A dashboard poll is never logged out in the middle of an API call, and it does not count as the connected administrator's own activity, so it cannot keep a real person signed in past the idle limit you configured. The parts that cannot work on a private site are the ones that fetch your pages anonymously from the vendor's servers: uptime monitoring, broken-link checking, and SEO or page-speed scans. Those requests carry no login, so they receive the login redirect and the service will usually report the site as down or its links as broken. Switch those particular monitors off for private sites. There is no way to satisfy them and stay private.

Membership plugins are built to sell access: they manage subscription levels, process payments, and drip-feed content to paying customers. All-In-One Intranet is built for internal, private sites where everyone who logs in is already a trusted member of your organization. It locks the entire site down to logged-in users in one click instead of gating individual posts behind a purchase or subscription tier. If you need to charge for access, use a membership plugin; if you need a private company intranet, this is the simpler fit.

Yes. All-In-One Intranet works at the authentication layer and does not change how your pages are built or rendered, so you can design your intranet with any page builder and the privacy enforcement still applies to the finished pages. If a builder's live preview appears to redirect to the login screen, that is expected for a logged-out request. Edit while logged in and the builder behaves normally.

No noticeable impact. The privacy check runs early on each request and is a simple logged-in or logged-out test, and the auto-logout feature reads and updates a single session record per page load. There are no external calls and no heavy database queries involved.

Yes. The plugin relies on WordPress's standard authentication, so it does not replace or restyle your login screen. If you use a custom login page plugin, unauthenticated visitors are sent to whatever login URL WordPress is configured to use, and your branding is preserved.