Restricting access to your site

Sometimes you don't want the whole internet looking at a site. Maybe it's an intranet for your team, a staging copy you're still working on, or an admin-only area you'd rather nobody stumbles into.

This page covers four things you can set up yourself, from your own files, with no support ticket needed:

• keeping the admin pages quiet against bots,
• locking a whole site down to just your own IP addresses,
• locking only the login/admin area to your own IPs while the rest of the site stays public, and
• deciding which AI crawlers and assistant bots may read each site.

All are safe to turn on and easy to undo, and none can accidentally lock you out.

Everything here you do from your own account — either by editing a small text file over SFTP, or with nano in your shell. You never touch the server itself.

Which one do you want

It helps to know which of these you actually want before you start, because they protect different things:

• Admin-page protection — a setting that's already on by default for every site. It quietly bounces anonymous bots away from your /admin pages so they can't hammer your login. Most people never need to think about it — but occasionally it gets in the way, and then you'll want to know how to switch it off. This one is a line in your site's INI file.
• Whole-site IP lock — an opt-in you set up when you want a site reachable only from a short list of IP addresses (yours, your office, your team). Everyone else gets a plain "403 Forbidden". This one is a line in a control file.
• Login/admin-only IP lock — an opt-in like the whole-site lock, but scoped to just the /user and /admin pages: the public site stays open to everyone, while only your listed addresses can reach the login and admin area. Ideal for a public site where you still want the back office reachable only from your own connections. Also a line in a control file.
• AI crawler and assistant control — a per-site policy deciding which classes of AI bot (training crawlers, AI search, assistant fetchers, utility bots) may read a site. Sensible defaults are already in force everywhere; you only add a line when a site wants something different. This one is a line in a control file too.

Pick whichever matches what you're trying to do. They're independent — you can use any, all, or none.

The admin-page protection (and how to opt out)

By default, when someone who isn't logged in asks for one of your admin-ish URLs — anything starting with /admin, plus /logout, /privatemsg, and /approve — the platform sends them straight back to your homepage instead of letting the request reach Drupal.

Why it does this: those pages are never cached, so every hit lands directly on Drupal. Bots love to pound the login page, and this stops them cheaply, before they get anywhere. It costs you nothing and you didn't have to set it up. For nearly every site, leave it exactly as it is.

There's just one situation where you'd want it off. Every so often it can catch a real person: if your own browser is holding an expired session or a stale cookie, you might click something under /admin and find yourself bounced to the homepage even though you thought you were logged in.

If that keeps happening and clearing your cookies doesn't settle it, you can turn the protection off for that one site.

Turning it off

You do this with a single line in your site's INI file. That file lives at:

sites/<your-domain>/modules/boa_site_control.ini

Open it over SFTP (create it if it isn't there yet), and add:

disable_admin_dos_protection = TRUE

Save, and you're done. There's nothing to click and nothing to run — the change is picked up on its own, usually within about a minute. (The full details of how to find and edit these INI files, and why the short wait, live on the INI settings page — this is just the one setting you need.)

Turning it back on

Either delete that line, or set it back to the default:

disable_admin_dos_protection = FALSE

Same short wait, and the protection is active again. Because the default is "on", even just removing the line restores it — you can't leave your admin pages exposed by forgetting to tidy up.

Careful with this one. Switching it off removes only the homepage bounce. It does not fling your admin pages wide open: there's a second, separate guard at the web-server layer that always refuses a /admin request from a client carrying no session cookie at all (a plain "403 Forbidden") and blocks known bots outright — and that guard stays on no matter what you set here.

So turning the setting off mainly lets a stale-cookie browser (which is the case you're fixing) reach /admin, where Drupal's own "Access denied" then takes over. It's still a small extra bit of exposure, so only turn it off if you actually have the browser-session problem above, and turn it back on once you've sorted it out.

Locking a whole site to your own IP addresses

This is the stronger control. Instead of protecting just the admin pages, it makes an entire site reachable only from IP addresses you list. Everyone else — every page, not just the admin area — gets a "403 Forbidden". It's exactly what you want for a private intranet, a staging site you're not ready to show, or an admin-only tool.

You set this up in a control file inside your own account:

static/control/ip/access.txt

On a typical account that's ~/static/control/ip/access.txt in your shell (the folder may not exist yet — just create it). Add one line per site: the site's name, then a space, then the IP addresses you want to let in, separated by spaces:

# static/control/ip/access.txt

intranet.example.com   203.0.113.10 203.0.113.0/24 2001:db8::/32
staging.example.com    198.51.100.42 2001:db8:1::1

A few things worth knowing as you fill this in:

• Use each visitor's real public address — the one a site like https://ifconfig.co shows them, not a home/office LAN address like 192.168.x.x.
• You can list IPv4 or IPv6 addresses, and either single addresses or whole ranges in CIDR notation (203.0.113.0/24, 2001:db8::/32), separated by spaces.
• The lock covers the whole site, not just certain paths.
• Lines starting with #, and blank lines, are ignored — so you can leave yourself notes.
• If your sites sit behind Cloudflare, this still works on the visitor's real address — the platform recovers it for you — so enter the real client IP just the same.

You don't run anything or click Verify. The change is noticed on its own and takes effect within about two minutes.

You can't lock yourself out

This is the part that makes it safe to try. On top of whatever IPs you list, three addresses are always allowed, automatically, so a typo can never strand you or the site:

• the loopback address (127.0.0.1),
• the server's own address, and
• any address currently connected over SSH — which includes you, right now, if you're working in your shell.

You never have to add those yourself, and you can't accidentally leave them out. Worst case, if you fat-finger an address and lock out the people you meant to let in, you fix the line and it corrects itself within a couple of minutes.

Opening the site back up

To lift the restriction, just delete that site's line from access.txt and save. On the next pass (again, within about two minutes) the site is open to everyone again. To remove all restrictions, empty the file or delete its lines. There's no separate "undo" step — removing the line is the undo.

Locking just the login and admin area to your own IPs

Sometimes you want the public site open to everyone, but the login and admin pages (/user and /admin) reachable only from your own connections — to keep bots and strangers away from the back office without hiding the site itself. That's this control.

It works exactly like the whole-site lock above, but it only guards /user and /admin (and the pages under them); everything else stays public. Anyone else who opens /user or /admin gets a plain "403 Forbidden".

Edit (or create) this file in the instance that hosts the site:

# static/control/ip/user_admin.txt

intranet.example.com   203.0.113.10 203.0.113.0/24 2001:db8::/32
staging.example.com    198.51.100.42 2001:db8:1::1

One line per site — the site name, then the addresses allowed to reach /user and /admin. As with the whole-site lock you can list IPv4 or IPv6 addresses, single or as CIDR ranges, separated by spaces; use each visitor's real public address. # comments and blank lines are ignored.

The same safety nets apply:

• changes take effect within about two minutes,
• your own address (loopback, the server, and anything you're logged in from over SSH) is always allowed so you can't lock yourself out of the admin area, and
• deleting a site's line lifts the restriction.

You can use this together with the whole-site lock or on its own.

Controlling AI crawlers and assistants

AI bots visit your sites for very different reasons — some crawl to train models, some index you so you turn up in AI search answers, and some fetch a single page because a person asked an assistant to read it. Your host sorts them into classes and applies a sensible default to each, the same on every site. You can change that default for any one site.

You don't have to set anything up for the defaults to apply — they're already in force on every site. Reach for this only when a particular site wants something other than the default.

What the defaults are

For most sites these defaults are exactly right, and you can leave this alone entirely.

Changing it for a site

You set overrides in one more control file in your own account:

static/control/ai/policy.txt

On a typical account that's ~/static/control/ai/policy.txt in your shell (the folder may not exist yet — just create it). Add one line per site: the site's name, then a space, then the changes you want. A site with no line keeps the defaults above.

You can combine flags on one line, in any order:

# static/control/ai/policy.txt

# A news site happy to be in AI training data:
news.example.com    train-allow

# A members-only shop that wants no AI bots indexing or fetching it:
shop.example.com    search-block user-block utility-block

# A blog that wants AI search but not the assistant "user" fetchers:
blog.example.com    user-block

# A research site that wants even the evasive Perplexity assistant allowed:
research.example.com    evasive-allow

As with the IP-lock files, lines starting with # (and anything after a # on a line) are ignored, and so are blank lines — so you can annotate freely, labelling which site each rule is for. The change is picked up on its own within about two minutes — no restart, no support ticket. To put a site back to the defaults, just delete its line; the override is removed on the next pass.

What stays on no matter what

A few AI-related protections are always on for every site and aren't set from this file:

• outright scrapers and download tools — the mass-harvesting bad bots,
• forged opt-out tokens — a request arriving as Google-Extended or Applebot-Extended (those are content-licensing signals, never real crawlers, so anything wearing one as its identity is turned away), and
• credential and dotfile probes — requests fishing for .env, .git, and similar secret paths.

These are blocked on every site and there's no line you can add here to change them. If one ever catches a genuine request you need to get through, that's one for your host to look at — the same as the server-level limits just below.

When it's not something you can set

The controls above are entirely yours — you own the files, so you own the change. But some access questions live at a level below your account, on the server itself:

• a firewall block,
• a country-level ban,
• blocking a specific abusive IP across all sites on the box, or
• anything that isn't one of your own sites.

Those aren't things you can reach from your account. If you need one of them, open a support request with your host — that's who has the access to do it.

Related pages

• INI settings — how to find and edit your boa_site_control.ini file, and the rest of the per-site settings you can change.
• Which file do I edit? — a quick guide to the site vs. platform files, if you're not sure which one you're looking at.
• Shell and SFTP access — how to connect so you can edit these files in the first place.
• Managing your sites — the day-to-day site tasks in your control panel.
• HTTPS for your sites — a private site should still be served over HTTPS.