inmake DOCS

URLs

URL structure: collection segments, categories, renames and aliases.

Website › URLs is where the project's addresses are shaped. It has three tabs: Structure — how the URLs are built — Addresses & redirects — the stored addresses and the redirects (described on the SEO page) — and Old addresses — the URLs of a previous site that should keep working (below).

Structure#

The tree shows every address shape the site serves, drawn from the project's settings (opening it reads no address data):

  • / — the homepage set in Website › Web › Site.
  • /slug — the flat addresses: every document, and the only address of a document whose collection has no URL segment of its own.
  • /segment — each collection with its own URL segment: its documents answer at /segment/slug and the canonical URL moves there. Below it come its categories (/segment/category), a row for documents without a category and Add category.
  • Collections without a segment, each with Give it a segment.

The language tabs above the tree redraw every path in that language — its segment and, when the language is in the URL, its prefix (/en/recipes/starters), exactly as visitors see it. A collection that uses its key because no segment is set for the language shows key fallback.

A collection's segment#

Select a collection to edit, per language, its segment (empty uses the collection key) and aliases, the Own URL segment switch and the listing page shown at the bare /segment. The same editor sits in the collection dialog under Data › Content.

A segment is refused when it isn't lowercase letters, digits and dashes, when it is a reserved platform path (m), when it equals a URL language code, or when another collection with its own segment already uses it — or has it as an alias — in that language (the second collection would never be reached). A note says when a page or a redirect already owns /segment in that language: it keeps that address and shadows the listing page, while the documents still answer under it.

Renaming a segment asks first and shows the old and new address. Segments are assembled, not stored, so no redirect is written for them: keep Keep the old segment as an alias ticked (the default) and old links answer 301 to the same page at the new address; untick it and they answer 404. Removing an alias asks too.

Switching the segment off asks with the number of documents affected: every /segment/… address answers 404 and the canonical URL returns to /slug. Documents published only under the collection URL (their SEO card's scope is collection) have no address at all until it is switched back on. The categories are kept — the tree shows them as inactive — and serve again as soon as the segment is on, with no document to re-save.

Categories#

A category gives a collection a second level, /segment/category/slug. Each document picks one in its SEO card; a document without one stays at /segment/slug.

  • Name — for the console only.
  • Key — derived from the name when you add the category; it can be edited until the first save and is then locked, because the category's addresses are stored under it.
  • URL segment per language — empty uses the key. Aliases (behind the disclosure) keep old segments answering with a 301. Two categories of one collection cannot share a segment or alias in the same language.
  • Category page — the page shown at /segment/category. A document of the collection whose slug equals the category segment owns that address instead; the panel names it.
  • Documents in this category — counted per language when the panel opens, with a link to the listing.

Renaming a category segment asks and offers the old segment as an alias, as for a collection. Remove is disabled while any document uses the category; once none does, it also offers to delete the former addresses documents left behind in it.

Editing the structure needs the web capability; members with content only see it read-only (they keep editing documents and their addresses).

Old addresses#

A site that moved to the platform leaves its old URLs behind — cached by search engines, printed on materials, used in campaigns — often in shapes the new site never builds: /cz/kampus/urbanity-kampus-tachov/, /produkt.php?id=12, /en/about-us.html. The Old addresses tab keeps them working: each entry is one old address and the address it now redirects to.

  • Old address — exactly as the previous site served it, a path or a full URL. Case, a trailing slash and a ?query are ignored; the dialog shows the form that is stored (/cz/kampus/urbanity-kampus-tachov). When the language is in the URL, the default language's prefix is removed, because the site strips it from every address before looking anything up — an old address under another language's prefix (/en/old-page) is kept with it.
  • Redirects to — a path on this site exactly as the visitor should land on it (with its language prefix when the target has one: /cs/kampus/urbanity-kampus-tachov) or a full https:// URL. The visitor's own ?query rides along, so campaign links keep their parameters. The old address itself is refused (a loop).
  • Temporary (302) for an address that will change again; otherwise the answer is 301 Moved Permanently.
  • A note for yourself (which site, which batch).

The lookup is a single direct read of the stored address — no search, no scan — and it happens only where the site would otherwise answer 404. A live page, an address with its own segment and a redirect set in Addresses & redirects always win, so the dialog tells you when the address is not free today: it already redirects somewhere, or a page lives there (the entry is still saved and applies once that page is gone). Old addresses are never listed in sitemaps.

Editing needs the content or web capability. For a long list, an assistant or an MCP client can add them one call at a time (setRedirect with from).