Docs
Delivery And Configuration
Choose how localized traffic behaves, when routes are crawlable, how locales are exposed, and how cautiously or broadly rollout should proceed.
The dashboard is a signed-in workspace. If you are new, create an account first. If you already have access, continue into the app and pick up the same guide there.
Rollout shape
Choose the right delivery posture
Delivery settings determine what visitors and bots can actually encounter. They are the core technical product controls.
Delivery modes
Runtime-only
Use this for fast rollout, customer proof, and controlled user-facing localization without making localized routes part of the search footprint by default.
Indexable SEO
Use this when localized routes should become crawlable. This mode needs stronger release discipline because search exposure has a longer tail.
Locale URL strategies
Path prefix
URLs look like `example.com/fr/...`. This is usually the easiest default when one hostname should serve many locales.
Locale subdomain
URLs look like `fr.example.com/...`. Use this when subdomains match market ownership, existing infrastructure, or brand structure.
Exposure control
Control which locales can appear
Locale access policy is where you choose how open or controlled the rollout should be.
Locale access policies
Approved locales only
The safest default. Only locales that have been explicitly approved participate in normal localized delivery.
Allowlisted locales
Use a named list when the business wants even tighter control than approval alone, such as phased launches or region restrictions.
Any presented locale
Useful for exploration and broad presentation, but not the best default when launch control matters most.
Unknown locale flow
When a visitor asks for a locale that has not already been prepared, the safest behavior is a branded locale chooser with a safe return path back to the original page.
That keeps the user oriented, preserves the request context, and avoids pretending unsupported locales are fully launched.
Eligibility
Choose route governance intentionally
Not every route deserves the same localization posture. The product should help you keep that distinction visible.
Usually good candidates
Marketing pages, docs, blog, landing pages, and selected commerce-content routes are the natural starting point for rollout.
Conditional candidates
Search, form-heavy, and unknown route classes can work, but they deserve explicit enablement and closer observation.
Usually not appropriate
Auth, checkout, cart, account, dashboard, and user-specific routes usually carry too much risk for generic localization rollout.
Translation profile
Use the technical translation settings well
The translation profile is where you define the technical shape of what can be translated and how cautious the product should be.
Key settings
Framework hint
Choose the profile that best matches the source site so the product starts from the safest understanding of the page shape.
Include selectors
Define what part of the page is intended for translation. Narrow selection is often the best way to build confidence.
Exclude selectors
Protect risky fragments like embedded apps, widgets, app chrome, legal notices, or UI that should remain untouched.
Metadata mode
Translate safe metadata fields when localized discovery matters. Preserve them when you want a more conservative launch posture.
JSON-LD mode
Translate supported structured fields when localized search behavior matters, or preserve them when source-authored schema should remain canonical.
Protected terms in the translation profile
Use these to reinforce brand-profile decisions wherever rendered or structured content is passing through translation handling.
Recommended default posture
- Start with `generic-html` unless you know a better fit.
- Use a narrow include selector like `main` when you want a conservative first launch.
- Add exclude selectors only after a fragment proves risky.
- Preserve metadata if you are not yet ready to optimize localized search behavior.
Go live
Connect the hostname and verify launch
DNS is the final technical handoff from setup to live delivery. The product should make it feel concrete and verifiable.
Step 01
Issue the hostname target
Get the expected target from the Delivery surface so the DNS change is unambiguous.
Step 02
Point the hostname correctly
Create the required DNS mapping so your site hostname routes through the localized delivery layer.
Step 03
Verify from the product
Use the verification step in the app to confirm the target matches what the delivery layer expects.
Step 04
Treat verified DNS as launch readiness
A locale is not meaningfully live until the hostname and delivery configuration can actually act on real traffic.