01
Private site: use Force users to login
Moodle’s Force users to login setting is designed for this exact case. When it is enabled, unauthenticated visitors must authenticate before they can see Site home. In current Moodle administration the security settings sit under Site administration → General → Security → Site security settings; wording and menu grouping can vary slightly across supported versions.
- Use this when the LMS has no meaningful public-browsing purpose.
- It is a better system-level rule than redirecting only the root URL, because authentication is enforced consistently rather than cosmetically.
- Review guest access separately. Requiring login before Site home and allowing guest access to particular courses are different configuration decisions.
- Keep the login experience concise: organisation identity, authentication method, password/help route and only the guidance people genuinely need to enter.
02
Mixed audience: keep Site home public on purpose
If prospective participants, clients or other non-authenticated visitors need useful information, do not force them through login simply to preserve a clean screen. Current Moodle Site home settings allow different content choices for visitors and logged-in users.
- Configure Site home from Site administration → General → Site home → Site home settings.
- Keep the public state small: what the site is, who it is for and a clear way to log in or find the relevant public information.
- Do not expose a long course catalogue to guests simply because Moodle can render one there.
- Treat public Site home as a product surface with a job, not as a collection of available blocks.
03
Decide where signed-in users should land
Login and post-login destination are separate decisions. Moodle can send authenticated users to their Dashboard or to Site home, and the appropriate choice depends on whether the user usually arrives to resume their own learning or to browse a shared catalogue.
- Dashboard is usually stronger when returning participants mainly need their enrolled courses and progress.
- Site home can be stronger when the shared catalogue, announcements or organisation-wide entry points are the real destination.
- Current Moodle documentation places the “Home page for users” choice under Site administration → Appearance → Navigation.
- Test this with the actual audience rather than choosing the prettier first screen in an administrator session.
04
Avoid a web-server redirect unless you really need one
A reverse-proxy or web-server rewrite from `/` to `/login/index.php` can force a particular URL, but it is not the normal answer to a Moodle access-policy problem. It can also make a future public Site home, SSO flow or alternate authentication route harder to introduce.
- Use Moodle’s authentication policy first.
- Use a direct login link in invitations or bookmarks when that is all you need.
- Only add infrastructure-level redirects when there is a separate routing requirement and you have tested authentication, logout, password recovery and SSO flows.
05
A quick decision rule
- 01
Ask whether unauthenticated visitors have a legitimate job to do on the Moodle site.
- 02
If no, enable Force users to login and design the login experience well.
- 03
If yes, keep Site home public and make its guest state intentionally useful and small.
- 04
Choose Dashboard or Site home separately as the signed-in destination.
- 05
Test the flow signed out, signed in, after logout and through any SSO/magic-link path before calling the entry experience finished.