Stored Builds and Search Engine Pings

What a Stored Build Is

When you publish, Websites can also build your website into finished files and keep them in your own storage, in your account's data region, ready to be served quickly. The builder is given your published version, your company's details, and the platform feed, draws every page exactly as your live website shows it, and keeps nothing itself. Nothing runs on any outside server, and nothing about your website is kept anywhere but your account.

Visitors at your website's own address get the stored build (Custom Domains), so a website served at its address needs stored builds on. Preview in the workspace still draws from your working copy.

Turning It On

Stored builds start off. Whoever manages Websites (owners, admins, or anyone whose role allows changing Websites Settings) turns them on (action sites.build.switch), and can turn on two pings with them:

• Ping IndexNow. After each build, IndexNow is told the addresses of the pages that are new or changed, for each of your website's addresses. Websites makes your own IndexNow key once and publishes it as a small file on your website, which is how IndexNow knows the website is yours.
• Ping Google. After each build, Google's Indexing API is told about each page that is new or changed, at most 100 a day, newest first. It uses your own Google Search Console connection (Settings, Connections), so connect that first. Turn on the Indexing API for the same service account in Google Cloud Console and make the service account an owner of the site in Search Console. Google says it may ignore pages that are not job posts or live streams.

Pings are sent after a build, so building has to be on for either ping. An assistant or API key cannot turn any of these on.

What Happens When You Publish

1. Publish (or go back to an earlier version) as usual.
2. A short while later, the version is built and stored. When you publish twice quickly, only the newest is built.
3. Only pages whose content changed are stored again, and only they are sent to IndexNow and Google.
4. If storing does not work, it is tried again a few times with a wait, then stops and says to publish again.

A build is what your live website shows at that moment, including the code snippets that are on and maintenance mode. A price or snippet you change later reaches the stored build at your next publish.

Platform Facts on Your Pages

A page can show facts about the platform with a placeholder in its text. They are filled in the stored build:

While stored builds are on, a publish with a placeholder nothing fills (a misspelled one, for example) is refused and names it, so your live website and the stored build never disagree. The preview shows the placeholder itself.

Seeing Your Builds

See the stored builds of your websites (action sites.build.status) shows whether building and each ping are on, whether Google Search Console is connected, and the latest builds: the version, whether it was built, how many files and bytes, a plain reason when it did not work, and how many pings were sent. Anyone who can see websites can see it. Builds and pings are in Export Everything as Website Builds and Website Search Engine Pings.

Stored Layout

For the website serving platform: every file is kept under your account's own id. Each file's content is named by its SHA-256 (sites/<account>/o/<sha256>), never by a page name. Each version has a file list (sites/<account>/<website>/v<number>.json) with each address's file, type, and status, the Page Not Found answer, the redirects, and the pictures. A pointer to the current version (sites/<account>/<website>/current.json), and one for each active address (sites/<account>/host/<address>.json), are written after everything they point to. An address taken away, or the addresses of a removed website, get their pointer marked removed by the next build (never deleted), so they stop being served.