Operators handbook: under construction

A website is publicly reachable the moment its hostnames exist. Adding a WebsiteHost row is what generates the ingress and the certificate, so there is no quiet period between "the tenant was created" and "anyone with the address can read it". Building happens in the open unless you close it.

Websites → General → Under construction is what closes it. While it is on, every visitor whose address is not on the allow list gets a "coming soon" page instead of the site, and the people building it carry on as normal.

This is a per-website switch, not a module. Every tenant has it.

It is not the same as hiding from search engines

The two settings sit next to each other and sound alike. They are not alternatives, and the difference is worth being exact about:

"Hide from search engines" asks crawlers to look away and does nothing else. A link pasted in a chat, a client who was given the address last week, a competitor who noticed a certificate being issued: all of them read the half-built site.

So the honest split is that noindex protects your search results and under construction protects the site. A site being built usually wants both, and a new website gets both switched on.

Turning it off is the launch

A new website gets it switched on. A site is reachable long before it is ready to be read, and starting open means the window between "created" and "someone remembers to hide it" is served to the public.

Which means the launch checklist has this on it: turn it off when the site goes live. The failure mode is quiet, because a site left held looks completely normal to whoever built it — they are on the allow list, so they see the real site every time they check. Everyone else sees the placeholder. That is why the setting is badged on the website list and carries a standing banner on the website's own screen: it is meant to be hard to forget rather than hard to switch.

Any admin of the site can turn it off. It is deliberately not super-only: lifting it is the launch, and the person who built the site is the one standing there when it happens.

What a blocked visitor gets

A "coming soon" page carrying the website's name, and an HTTP 503.

The 503 is the part that matters and it is not a detail. A 200 placeholder is a page like any other: a crawler may index it, and then keep showing it in results after launch. A 503 means "not available, come back later", which is exactly true, and it is never indexed. The response also carries Retry-After and noindex.

The page is deliberately plain. It carries its own markup and reaches for nothing the theme owns: no base template, no stylesheet, no menus. A site under construction is precisely a site whose theme is half-written, and a placeholder that renders through the thing being worked on goes down with it.

A theme that wants its own holding page can ship templates/construction.html.twig; it replaces the built-in one and receives the website in scope.

Nothing from a held site is cached anywhere, because what the response contains depends on who asked for it.

The allow list

Websites → General → Under construction → Addresses that see the real site. Add a single address, or a range in CIDR notation. Remove with the × on the chip.

Under the field you will see "You are connecting from …" with an Add it link. That is your own address as the site will actually see it, not a guess: it comes back from the server, over the same route the site uses. It is offered rather than filled in for you, on purpose. Adding an address is a decision, and a list nobody chose is a list nobody can account for a year later.

If you save a non-empty list that does not contain your own address, the screen warns you first. This is the one mistake the feature invites, and it is self-concealing: the page that would tell you that you are locked out is the page you can no longer reach.

Two lists, added together

The list on this screen is not the whole story. There is a second, deployment-wide list that applies to every tenant at once, and the two are added together rather than one overriding the other.

The practical consequence: an empty list on this screen does not mean nobody can get in. Our own connections are already covered centrally and are not repeated per site. Use this screen for the extras — a freelancer building one site, a client who wants to watch it come together — so that opening one site to one person does not need a cluster change.

Changing the deployment-wide list is an infra job, not an admin one.

ZenRise still sees the site

An SEO audit of a site under construction works, and needs no setup per site.

ZenRise runs on the same cluster as the sites it audits, so its crawl arrives from inside and matches the cluster's own ranges on the deployment-wide list. There is nothing to add and nothing to switch off first.

What is not affected

• The editor. The admin renders pages through cms-api, which never passes through the public site's gate. Editing, previewing and the inline editor all work exactly as before, from any address.
• Certificate issuance. /.well-known/ is never held back, so a certificate can still be issued for a site nobody may read yet. Holding it would be circular: the site cannot be reached at all without one.

Which switch do I want?

• Building a new site — leave both on. They are on by default.
• Going live — turn both off, in either order.
• Live site, temporarily embarrassing page — neither. Unpublish the page.
• Live site you want out of Google — hide from search engines only. Under construction would take the site away from its visitors too.
• Rebuild of a live site — neither, on the live tenant. Build the rebuild as its own website under construction and swap the hostnames at launch; switching a live site to under construction takes it off the air for everyone who currently uses it.