SEO

The Website area collects the search-facing settings of the site. How the addresses are built — collection segments and categories — is on the URLs page.

Search defaults#

Site-wide title pattern, default description and social image — what a page falls back to when its own SEO side tree is empty.

Title pattern — %s stands for each page's own title: %s | Acme turns Kontakt into Kontakt | Acme on every page. It is not applied to the homepage, to a page without a title of its own (that page shows the site title), or to a title that already ends with the pattern's suffix — so a project that typed "| Acme" into its titles can adopt the pattern and remove the typed suffixes at its own pace. Shares (og:title) carry the bare page title. Blank = every title exactly as written.

Meta tags — custom <meta> tags as key–value rows, here for every page and in each document's SEO card for that page: og:type, og:site_name, twitter:card, article:author, fb:app_id, robots… A key may repeat (og:image, article:tag). Open Graph keys (og:, article:, product:, profile:, fb:…) are written as property=, everything else as name=. Which tag wins, from most to least specific:

1. the page's own meta tag;
2. the page's SEO title, description and image (which produce og:title, description / og:description and og:image);
3. the site's meta tag;
4. the site's SEO title, description and image.

So a page's og:type replaces the site's, a page's og:title meta tag replaces the one made from its SEO title, and a site og:image tag shows only on pages without their own SEO image. og:url and og:locale always come from the page itself.

The SEO card's ✨ Generate also fills the social tags: og:type (website, article, product or profile, picked from the content), og:title and og:description written for sharing (no "| Brand" suffix), and twitter:card. Tags you added under other keys stay.

Structured data#

Site-wide JSON-LD (organisation, website, breadcrumbs) merged into every page; documents add their own (the document's Structured data section). Where a document declares a @type the site records also have, the document's record replaces the site one on that page.

Indexing#

robots directives and the sitemap settings; the render server serves robots.txt and the sitemaps from them.

Named user agents. Besides the general User-agent: * rules, robots.txt names the crawlers in the Named user agents list, each in its own group repeating the site's rules (Allow: /, or your Disallow paths) — a crawler that finds its own name ignores the general group, so the rules have to be spelled out for it. The list starts with the AI crawlers — GPTBot and OAI-SearchBot (OpenAI), PerplexityBot and ClaudeBot (Anthropic) — and you add or remove names as you like; an empty list names nobody. A custom robots.txt body replaces all of this.

What the sitemaps list. sitemap-pages.xml holds the homepage, the developer's static routes and the documents of the Pages collection — the Pages row is always on. Every other ticked collection gets its own sitemap-{collection}.xml. In cookie mode with no collection besides Pages, sitemap.xml is that same pages list; otherwise it is an index pointing at all of them. A page is listed at its main URL only: aliases, former URLs, redirects, the homepage's own slug (the homepage is listed as /), the 404 and maintenance pages, and any document you hid with Choose pages, are always left out — search engines should see each page once, at its canonical address. A very large site is cut at 50 000 URLs or 50 MB per file.

When the language is in the URL (Website › Web › Site › Language in URL, path mode), every sitemap — sitemap.xml included — lists each page once per language at its own address (/about, /en/about), and every page's head carries hreflang links naming its other language versions, og:locale and a canonical URL — over the project's first custom domain, so they appear once one is connected. With the language in the URL, every sitemap is also split per language: sitemap.xml becomes an index of sitemap-pages.cs.xml, sitemap-pages.en.xml, sitemap-recipes.cs.xml, … — one file per collection and language, each holding only that language's addresses and each with its own 50 000-URL / 50 MB limit, so a large collection fits once per language. The sitemaps themselves carry no language links: Google reads the language versions from the page heads, and declaring them a second time in the sitemap brings no benefit. The undivided sitemap-{collection}.xml files keep answering for anything that already points at them. The Indexing page has one preview button per language on each row. In the default cookie mode a page has one address for every language, and a crawler (which carries no language cookie) always sees the default language there, so the sitemaps list only the default language's URLs (plus entries without a language). The Indexing page says so on a multilingual project; turn on Language in URL to list every language.

These files are served on a custom domain only. The platform address ({store}.inbs.dev, and every demo-… address) always answers a fixed Disallow: / for robots.txt and 404 for every sitemap, so it never competes with the real site in search — the notice at the top of the page says which case applies to the project. To see the files anyway, each served one has a preview (eye) button — robots.txt and sitemap.xml on their card headers, the static-pages sitemap and every enabled collection sitemap on their rows — that opens a virtual copy built in the console from the settings as currently edited, unsaved changes included, with the same rules the render server uses. The dialog says whether the file would actually be served (a switched-off sitemap, an unpublished site or an unenabled collection answer 404) and lists a collection sitemap's published page URLs; Copy puts the text on the clipboard.

Choosing pages. Choose pages under the Pages row opens the list of a collection's documents — Pages by default; pick another in the dialog, since a site's static pages can live in any collection — with each document's address in every language, its role (Homepage, 404 page, Maintenance) and a toggle. Every document with an address is listed by default; switch one off and it is left out of every sitemap (Hidden) while it keeps serving at its address. The homepage is always listed as / and the error pages never, so they have no toggle; a collection that isn't ticked in the list has no sitemap at all, and the dialog says so. The choices are part of the page's settings — they show in the previews at once and are saved with Save. The count next to the button says how many documents are hidden.

The homepage has one address. The page served at / (set in Website › Web › Site) is never listed under its own slug, and that slug answers a 301 redirect to / (/en in English when the language is in the URL), so search engines never see the homepage twice. The document editor's SEO card marks the homepage.

Addresses and redirects#

Website › URLs › Addresses & redirects lists the stored addresses of one registry — the root URLs (/slug), a collection with its own segment (/segment/slug) or one of its categories (/segment/category/slug); pick it in the select beside the title. Each row is one address (its key, e.g. kontakt) with one cell per language saying what a visitor in that language gets:

• page — the document that owns the address in that language (Show titles replaces the collection/id with the document title);
• alias — the same, through one of the document's slug aliases;
• former — an old slug of a document: it answers a 301 to the document's current address, so renaming twice still goes straight to the newest one;
• → target — a redirect (every language when it is set for all of them);
• falls back — the language has nothing of its own and the address answers what another language has (same language first — en_GB → en_US — then the default language, then the others).

The pills narrow the list to pages, former URLs or redirects, the search box matches keys, pages and targets, and Filter keeps only the addresses that have something in one language.

Pages own their cells: two documents may use the same slug in different languages (menu in Czech and in English), but within one language an address belongs to one page — a page saved with a slug another page already holds in that language keeps its slug, but the address is not registered (its SEO card warns before you save). To move a page's address, change its slug in the document; the old one becomes a former URL by itself.

An address's page (click a row) shows the same per-language answer with the reason, and:

• Redirect — No redirect, Same for every language or Per language. A redirect wins over the page of its language (the save asks before it hides one). Temporary (302) is for a campaign or seasonal address; otherwise the answer is 301 Moved Permanently. Two target shapes are accepted: a full https://… URL (sent as typed — a #fragment is kept) or a path on this site — about, /about, news/item, optionally with a ?query (the visitor's own query string rides along when the target names none, so ?utm=… links keep working). Anything else is refused: a //host target, another scheme (javascript:, mailto:), spaces or line breaks, and a target that points back at the address itself. When the language is in the URL, a per-language path stays in its language (contact for English goes to /en/contact); a redirect for every language is never given a language prefix.
• Test this address — pick a visitor language and see every step of the lookup the site runs, which one answers and the result (200, 301 → … or 404).
• Retire on a former URL removes it — the address then answers 404 or can be taken by another page.
• Delete address — only when no page owns a cell (change the page's slug instead).

New redirect creates one: the registry and the key, who answers at that key now, every language or chosen languages (a language whose page would be hidden starts unticked — "keeps the page"), a target per language and Temporary. In the root registry a key that is a collection's segment in some language is refused — the collection's address always wins there.

Redirects and former URLs are left out of the sitemaps, and a redirect is never cached as a page: a new or edited target is live within about two minutes (the render server's one-minute config window plus the CDN's). Because 301 is permanent, browsers that already followed one may keep doing so from their own cache — check the target with Test this address or in the Studio preview before you publish one.

Old addresses of a previous site — URLs in any shape the new site never builds (/cz/kampus/x/, /produkt.php) — are not registry addresses: they have their own Old addresses tab, described on the URLs page. They answer only where nothing in the registry does.

A page's addresses (the SEO card)#

The document editor's SEO card shows, per language, the addresses the page will have — the collection address (★, canonical) and the flat /slug — and:

• URL category — shown when the collection has categories (see URLs) and the scope is not Root only: the middle part of the collection address, /segment/category/slug. A new language copy starts in the category its other languages use.
• A pending change — when you change the slug, the category or the scope, the card says which current address becomes a former URL and redirects (301) to the new one when you save.
• Former URLs — opened on demand: the old addresses that redirect to this page in this language, each with Retire.
• Taken warnings — another page's slot, or a redirect, at the same key in that language: the slug will not be registered until it is free.

Traffic#

The Statistics page.

Search defaults, structured data, indexing and the URL structure need the web capability; addresses and redirects need content or web.