How do you translate a Statamic 6 website across several languages without breaking collections, inherited fields, localized routes or search results? This Statamic multilingual localization guide explains the multi-site feature, site configuration, the Localizable field setting, content variants, language switchers, Antlers and Blade templates, caching and international SEO. It is designed for content editors and developers building reliable world-facing websites.
In Statamic, a site can represent a language, region or related publication within one content system. Multilingual content therefore has at least three separate questions: which site is being requested, which values belong to that site’s content version, and what the frontend actually displays. A successful translation is not merely a saved French entry if the page uses an English navigation label, missing localized relationship or stale cached output.
The most dependable Statamic translation workflow starts by choosing target audiences and URL structures, enabling multi-site correctly, setting which collection fields are localizable, preparing language-aware templates and reviewing complete reader journeys. The guide then tests source and target content, accessible controls, search, redirects and release behavior. It uses concrete examples and clear decisions rather than assuming that a platform setting automatically creates an accurate translation.
Quick working summary
- Treat each site handle, URL and locale as a deliberate publishing contract.
- Plan multilingual content ownership before moving existing entries into multi-site.
- Use Localizable only for fields that genuinely need distinct values.
- Keep source identity and shared facts stable while reviewing target-language meaning.
- Make navigation, forms, related entries, SEO, caching and accessibility part of localization.
- Test direct public URLs and record approvals before enabling a translation.
A useful running example is a fictional public library publishing practical learning resources in English, French and Arabic. Its guides share stable book identifiers but use different introductions, translated categories and sometimes different library opening hours. We will follow one resource from content modeling through publication, recognizing that translated content and region-specific services are not necessarily the same thing.
Understand what multi-site actually provides
Statamic’s official documentation describes multi-site as a Pro feature for variations of a related site, not a general system for running unrelated tenants. A site can have its own handle, name, URL, locale, language choice and optional attributes. Those values influence how content is organized and presented, but they are not a substitute for a coherent editorial translation strategy.
The precise configuration paths, extensions and editor options can change with the Statamic release installed by an organization. This guide describes the verified Statamic 6 concepts, and recommends checking the running release and official documentation before making production changes. Treat each example as an architectural decision to test, not a file to paste blindly.
1. Define the reader, language and region
Begin with the person who needs the information. A French reader in Belgium and a French reader in Canada may need the same explanation of a science concept but different contact details or program eligibility. A site can reflect a language, a market or a blend; the publishing team must agree what its URL promises.
List the principal audiences, useful locales, available reviewers and the actual services offered in each destination. If no one can review a target language, creating a URL merely to appear international can damage trust. Start with fewer complete journeys rather than a large collection of superficial translations.
Make a small field matrix using the library example. Book titles that are officially published in several languages may require a bibliographic policy, while ISBN identifiers remain stable. Reading-program descriptions need natural language and local branch opening hours need their own factual source.
Before implementation, walk through a likely question: can a parent find a suitable reading activity, read its requirements, confirm where it is offered and submit a request entirely in the chosen language? If not, the site plan needs more than translated page headings.
2. Choose domains, subdomains or language paths
Statamic sites can use different URL roots. A translation may live at example.org/fr/, a French subdomain or a separate domain, according to the team’s content and infrastructure needs. Every option has consequences for cookies, hosting, redirects, search indexing and the language switcher.
Record the full canonical target for a sample resource before translating it. Compare /en/resources/reading and /fr/ressources/lecture, or an equivalent policy. A translated route can help the reader, but it also needs controlled redirects if an editor later changes its public slug.
Do not assume the root URL should be redirected based only on browser preference. A reader may intentionally follow an English link while their device prefers another language. If language detection is used, preserve an explicit language choice and make it easy to reverse.
Test every destination with a direct address-bar request rather than navigating there through an already established session. Confirm that the domain, TLS certificate, host configuration and app URL resolve correctly in staging and production.
3. Understand site handles and the sites configuration
Statamic identifies each site by a handle. The multi-site documentation places site configuration in resources/sites.yaml and explains the importance of stable handles for content directories and collection settings. A human-friendly name can change more easily than a handle already used by stored content.
Choose handles that are legible and unambiguous, such as en, fr or fr_ca where justified. Do not put marketing claims or temporary campaign labels into a technical identifier. Document each handle alongside the actual audience and language code to avoid confusion when collaborators join later.
Renaming an established handle can involve content paths, global files, trees and configuration references. Treat that as a migration requiring inventory and testing, not as a cosmetic label edit. In a version-controlled site, plan the repository changes and the deployment together.
Inspect an existing source entry and one localized counterpart. Identify their site association, storage and public URL. When a reviewer knows which handle is active, a surprising English value in a target page can be traced more quickly.
4. Enable multi-site with a safe migration plan
Statamic documents a multi-site setting and a command for converting an existing content structure. The existence of a conversion tool does not remove the need to back up data, understand version control and inspect all deployed environments. Production conversion should have an explicit rollback route.
Inventory collections, taxonomies, globals, navigation trees, forms, routes and custom add-ons before enabling another site. A content type that was designed for one global language may include embedded assumptions about URL prefixes and fixed menu labels.
Run a conversion on a staging copy and compare representative entries before and after. Verify IDs, slugs, hierarchy, references and publication states; do not assume that a successful command exit means every template understands locale variants.
Build a release log identifying who performed the conversion, the repository revision, the tested URL set and the intended behavior. If a custom module or template produces a mismatch, roll back the affected change deliberately rather than trying to repair content while the site remains unstable.
5. Distinguish locale from language
Statamic’s site locale can influence regional formatting of dates, numbers and other data. Its language setting can select language strings and interface behavior, although frontend translations must still be supplied where appropriate. These values should reflect the intended reader rather than simply matching the site’s visible name.
A French-language site might use a locale aligned with France, Switzerland or Canada. The choice matters for presentation, but it does not confer legal rights to a program or change the underlying value of a measurement. Keep content eligibility and formatting decisions separate.
Write a small matrix with a calendar date, decimal number, postal address and time-zone-sensitive event. Check how each appears in the generated page. A string that looks correct to the developer may still be ambiguous or culturally unnatural to its intended audience.
If a localized page shows the right words but an inappropriate date format, inspect locale configuration and rendering logic. If the date has changed meaning or moved by a day, examine time-zone conversion and the source value instead of treating the issue as a vocabulary problem.
6. Decide which fields are localizable
Statamic’s documentation says existing fields are not automatically enabled for multi-site editing and identifies the globe control for making a field Localizable. This allows an editor to vary an appropriate value across sites. It does not imply that every field should have a separate translation.
Mark the educational guide title, summary, main text and image caption as localizable when they require approved target wording. Keep a resource’s stable machine identity and reference number shared. A region-dependent action label or branch address may need a separate ownership decision.
Not every field’s value is human language. Numeric identifiers, media references, logical flags and external keys can be damaged if copied into language-specific variants without a purpose. A field inventory makes this visible before translators begin working.
Test by changing one localizable field in French and one shared field in English. Compare every site version. If the edit appears in unexpected places, fix the model before using it on hundreds of resources.
7. Understand inherited and overridden values
Statamic content can inherit values from an origin when a target variation has not supplied its own value, depending on configuration and content structure. This can be helpful for shared facts but dangerous for text that readers assume has been translated. A missing French introduction should not quietly masquerade as approved French text.
Define an explicit rule for acceptable fallback. A universal ISBN can remain the same in every locale. A classroom safety instruction, privacy notice or booking policy may instead require an approved local version before the page becomes public.
Ask an editor to identify inherited versus overridden values in a representative entry. Then change the source description and inspect whether the target still shows its reviewed translation or has inherited the new English text. Do not rely on memory or a visual label alone.
Quality assurance should include three states: a field with a reviewed translation, a field intentionally shared, and a field missing a required translation. If the frontend treats all three identically, the workflow cannot report translation completeness accurately.
8. Organize collections by site availability
A Statamic collection can be structured to publish content across the sites you define, but not every item belongs everywhere. A global reading resource may appear in all languages while a workshop at one physical branch is meaningful only for a particular audience.
Write down which collections are global, which are language-specific and which include local offers. Avoid filling an absent workshop with a near-equivalent invented event merely to make all locale URLs appear populated.
Content identity becomes especially important when a translated item is displayed in a collection listing. The reader must see the right title, language and destination, and the result must not imply that the local site provides a service that does not exist.
Build two test entries: one that should exist in every site and one that should exist in only one. Check listing, filtering, detail pages, RSS if used and sitemap generation. The site is correct only if all these surfaces respect availability.
9. Translate navigation trees carefully
Navigation is part of the message a site sends. A French content page with an English top menu or an Arabic page whose mobile navigation is reversed can leave the visitor uncertain about where to go. Statamic navigation structures require intentional treatment when sites diverge.
Keep the intended hierarchy understandable in the target language. A translated label need not be a literal word-for-word copy if local readers organize the subject differently, but a changed route should lead to genuinely relevant content rather than a superficially similar topic.
Review the complete path from homepage to collection listing to detail article and back. Breadcrumbs, footer menus and mobile navigation often use different templates or cached fragments; each should be tested independently.
Include unpublished entries in the navigation test. A menu may link to a source-language page because its translated destination has not been released. Decide whether to remove the item, label the fallback or delay the menu change.
10. Use language-aware templates
Statamic supports Antlers and Blade frontend approaches. Both can render site information and content values, but a shared template can still accidentally reference the default site or a global value when a target variant is needed. Template correctness is a separate test from translation correctness.
Inspect components that render navigation, related entries, dates, social previews and forms. The content editor may have supplied the right French summary while the card component selects the primary English version. Retyping the summary is not a sustainable fix.
Keep translation of fixed user-interface strings distinct from collection fields. A search button label belongs to interface messages; an article’s educational explanation belongs to authored content. This separation improves review and reduces the number of places where a word must be corrected.
Enter a deep translated URL directly and inspect rendered HTML, not just a control-panel preview. Confirm language attributes, target-language content, links and any values from shared components. Repeat after a cold cache request.
11. Configure a truthful language switcher
Statamic provides a locales tag for linking to localized versions of entries or taxonomy terms. A language switcher should use such real destinations, not assemble links by mechanically replacing the first two letters of every URL. Translated slugs and unavailable content make string replacement unreliable.
Display only destinations that exist and are appropriate for the selected content. A reader studying a French guide should generally reach its English counterpart when switching languages, not be returned to an unrelated homepage.
Where no equivalent exists, choose a clear policy. A language option may be absent, disabled with context or lead to a labeled fallback. Do not disguise a general index as a translation of the specific page the reader requested.
Test switching from nested articles, category pages and the results of on-site search. Check keyboard focus and screen-reader labels. Try switching back and make sure the original entry remains identifiable.
12. Localize taxonomies and classification labels
Taxonomies are often treated as internal organization, yet their names appear in navigation, cards, search filters and breadcrumbs. A content item classified as ‘Study Skills’ should not display an unexplained English classification on a fully French resource page.
Choose a stable conceptual classification and provide natural target-language labels. Distinguish a taxonomy concept from a local service category: the first may be shared globally; the second may need a region-specific scope or a different structure.
An overly literal translation can confuse readers about educational levels or age groups. When school systems differ, explain the intended level rather than assuming two national categories are identical. Preserve the underlying educational requirement.
Test selecting a taxonomy filter, opening a result and returning to the list. Verify that result counts, breadcrumbs and URL paths remain consistent after a language switch and that missing localized terms do not silently erase relevant entries.
13. Handle relationships and shared resources
Connected entries make an educational site useful, but each link must consider language availability. A translated reading guide may reference a related research note or downloadable exercise that exists only in English. That is not automatically an error if the site signals the language honestly.
Record whether a relationship points to the same conceptual item in another site or to a market-specific resource. The former can support a coherent language switch; the latter may need a different review because the offer or jurisdiction changes.
Keep stable machine identifiers unchanged when they refer to the same source work. Translating a database key or external identifier can break relationships in a way that is difficult to detect from a visually correct page.
Create a small graph of three linked resources and one attachment, then browse it in each site. Open every destination, check page language and verify the resource matches the claim made by the source link.
14. Translate rich text and editorial blocks
Rich text is more than a paragraph of words. It may contain headings, emphasized terms, callouts, buttons, lists, citations, embedded videos and links. The translator needs the content’s purpose and structure, while the developer must preserve the markup and render it safely.
A heading that works in English might become considerably longer in another language. The layout should expand without hiding meaning. A cited scientific source should not be replaced with a translated-sounding title if the actual publication title remains in English.
Treat images with words inside them as a separate task. Either provide a localized graphic, a text equivalent or a clearly labeled original. A translated caption alone cannot make an unreadable diagram accessible to its target audience.
Inspect rendered rich text and exported content. Verify that list order, quotations, links, tables and embedded media survived the translation process. Check that translators cannot inadvertently alter executable syntax or unsafe external URLs.
15. Translate global content without losing ownership
Global sets often carry site-wide information such as contact details, promotional statements, social links and labels. The team must decide which values are language-specific and which belong to the organization or a regional service. Treating globals as universally shared can produce especially visible mistakes.
A worldwide education publisher may share its editorial mission while providing different local help contacts. A contact phone number must not change simply because its surrounding explanation is translated; it changes only when the service destination changes.
Clarify whether a local editor may change a global message for their site. If a promotion is controlled centrally, translating a promise about access or eligibility may require business approval beyond language review.
Test header, footer, newsletter signup, cookie information and contact area in every supported site. Since these components appear on many pages, one mistaken value can affect the entire translated publication.
16. Review image metadata and downloads
Accessibility and trust extend to assets. A photograph may be reusable, but its alt description, caption and displayed credit often require language-aware treatment. A downloadable PDF is not translated merely because the link label has been translated.
Create an inventory of important assets and decide which can remain language-neutral. Scientific symbols, logos and simple photographs differ from instructional diagrams with English arrows or safety notices embedded into the image.
For a library worksheet, identify the actual file language and file version. If a French page links to an English PDF, make that clear before the download. Do not let a localized label imply a document contains content it does not.
Check downloads, captions, image credits and accessible names through the public URL. Include mobile layout and screen-reader review; a correct file in the repository is not enough if the template displays the wrong link.
17. Localize forms and confirmations
Forms expose translation gaps quickly. The visitor may understand the guide but be unable to submit a request because validation messages, date hints or consent text remain in the source language. The form’s back-end notifications are part of the workflow too.
Translate labels according to the action, not as isolated dictionary entries. ‘Apply’ may refer to applying for membership, applying a filter or submitting a request; each needs context. A natural translation should preserve the user’s actual commitment.
Do not manufacture regional legal wording by translating a source policy without review. Privacy, accessibility arrangements and contractual conditions may need qualified ownership, especially when data is processed by a separate provider.
Submit a dummy request in each language and inspect the frontend errors, success page, confirmation email and staff view. Check that reference numbers, addresses and date values remain accurate and that translated field labels do not alter stored data.
18. Handle right-to-left languages
Statamic site information includes language-based text-direction behavior. Rendering an Arabic or Hebrew page still requires deliberate frontend design: icons, menus, numbers, mixed-script quotations and form controls need testing. Automatic direction is a useful starting point, not a comprehensive accessibility audit.
A page can set right-to-left direction while an embedded third-party widget remains left-to-right or places its labels out of order. Long Latin identifiers and book numbers can become especially confusing when inserted into sentences without appropriate text handling.
Do not reverse numeric values or change the order of scientific formula components to make the interface look symmetrical. Visual alignment and semantic order are different problems, and both must preserve the instruction’s meaning.
Test representative paragraphs, navigation, carousels, form fields, citations and tables with a fluent target-language reviewer. Use keyboard and screen-reader navigation, and inspect the rendered text direction at different viewport widths.
19. Plan search and locale-specific indexing
Statamic search can be configured for site content, but teams must decide whether queries should return only the selected language or include explicitly labeled results from other languages. An index that mixes titles and snippets indiscriminately can undermine an otherwise well-translated library.
Search for natural terms that readers actually use. A French student may describe a mathematical technique differently from a literal translation of an English category. Search relevance therefore requires editorial vocabulary as well as index configuration.
Review how changed and unpublished translations are added or removed from search. A stale result that points to a withdrawn language page is not solved by asking the translator to change the wording again.
Test queries, filters, no-results messages, pagination and destination URLs. Inspect result language labels and page titles. Compare the search experience with the source site without requiring identical word matching across unrelated languages.
20. Avoid static-cache language leakage
Statamic’s documentation notes that multi-site static caching requires appropriate configuration and server rewrite rules. A cached page served under the wrong site or host can expose the wrong language even when the database or flat files contain correct translations.
Trace cache keys, host and path handling through staging. Test the first request to a French URL from a clean session, a subsequent request to English and a return to French. The content should follow the requested destination, not the last language another visitor used.
Also test updates. A corrected target-language safety paragraph should become visible according to a documented invalidation or deployment strategy. A stale cache that keeps showing the old public text is a publication defect, not a translation defect.
Check proxy, CDN and application caching where relevant. Do not assume the CMS alone controls every layer. Record an operational procedure to clear or revalidate a specific localized URL without unnecessarily disrupting the whole site.
21. Distinguish SEO alternates from duplicate content
International SEO begins with distinct public destinations and meaningful content. Provide localized titles and descriptions, correct language attributes, stable canonical URLs and appropriate alternate-language signals where the frontend supports them. A translated page should not claim to be canonical to an unrelated or missing destination.
Hreflang can describe equivalent versions, but it is only useful when target URLs actually exist and lead to the intended reader experience. Do not list draft translations or map every article to a generic language homepage.
Regional language codes should reflect what the content actually targets. A site named ‘French’ is not automatically a Canada-specific offer. Avoid adding country attributes simply to capture more search traffic if the page does not serve that market.
Crawl a representative group of pages and inspect title tags, canonicals, alternates, sitemap entries, redirects and content language. Fix indexability and link errors before asking translators to rewrite perfectly good paragraphs.
22. Create controlled permissions and reviews
Multi-site editing is a team operation, so access should correspond to responsibilities. Statamic supports permissions related to site access; an editor who can review English resources does not automatically need authority over every language or global system setting.
Separate translation writing from publication approval where a high-impact resource needs independent review. An education article may need a factual subject reviewer and a language reviewer. A regional booking or privacy page may need service-policy approval too.
Use a review record identifying the source revision, target site, translator, reviewer and outstanding limitations. The word ‘translated’ should not mean merely that some text was entered; it should indicate what was checked and whether the page can be used.
Test the actual workflow with a restricted editorial account. Ensure that language reviewers can see the context they need without broad administrative permission, and that one editor’s incomplete variant cannot accidentally go live across every site.
23. Manage source updates and revisions
Source pages change after launch. A date is corrected, an activity is cancelled or a safety statement is clarified. Inherited fields, localized variants and deployment history must make these changes visible to the responsible language teams.
Use a change classification rather than sending every punctuation edit through an emergency review. Mark changes to facts, instructions, prices and eligibility as high priority. Preserve previously reviewed target wording while preparing an update rather than silently replacing it with the source language.
Version control and content revisions can help establish what changed, but neither automatically proves semantic equivalence. A reviewer should compare the actual claim before and after, then decide which target language versions need correction or withdrawal.
Run a rehearsal in which the source opening hours change while the French contact text stays approved. Verify that shared and localizable values behave as intended, that cache invalidation works and that the updated public page matches the approved record.
24. Build a release and rollback routine
Treat multilingual release as a small product launch. Define the source content revision, target-language approvals, page URLs, expected redirects, search behavior, accessible controls and the person responsible for a correction if an issue is found.
Launch one connected journey before a large archive: a landing page, an educational resource, a related item, a downloadable file and a contact form. This exposes relationships and user-interface defects that isolated content previews miss.
If a target page contains consequential misinformation, choose an explicit response: correct it, temporarily disable it or add a clearly labeled notice. An automatic source-language fallback is not always safe. Preserve the record of what visitors may have seen.
After publishing, visit the public page from a clean browser, verify the final URL and run the same tests used in staging. Record the review evidence so an editor can distinguish a future content defect from a release or cache fault.
Worked example: one reading resource in three languages
The fictional library’s source article is titled ‘How to use the night sky to find north’. It has a straightforward explanation, a diagram, a list of safety reminders, an audio alternative, three related resources and a registration link for a live astronomy workshop. The first editorial task is to separate universal educational facts from audience-specific services. The position of stars and the logic of the method must not be changed because a translation sounds smoother.
The project administrator confirms the English, French and Arabic sites in the configuration, selects clear URLs and prepares the appropriate localized fields. The editor marks title, summary, instructional text, diagram description and related-card labels for localization. Stable identifiers and links to the same source scientific reference remain shared unless a local alternative is explicitly approved.
The French translator sees the full diagram and knows that ‘north’ is a direction, not a brand or program title. The Arabic translator checks both wording and right-to-left display. Neither is asked to translate an ISO date string, a scientific coordinate or a registration code as ordinary prose. They may explain unfamiliar conventions, but the underlying factual values remain stable.
During testing, the French article loads correctly but a related-card component points to an English resource that is not available in French. The team keeps the link with an explicit English-language label rather than inventing a French destination. The Arabic page displays the diagram correctly but its direction arrow lacks an accessible textual description. That omission is corrected before publication.
The workshop registration form is market-specific. The team checks whether the advertised event is actually open to each audience and translates instructions only where the service exists. The final acceptance test covers direct URLs, the language switcher, search queries, metadata, accessible descriptions, downloads and a dummy form submission. A reviewer signs off on the complete journey, not merely on the body paragraphs.
Troubleshooting situations
A secondary site opens the wrong path
Check its configured URL root, host routing and generated links. Test a direct URL in a clean session before changing source content.
The target version shows English text
Check whether the field was marked Localizable, whether the target has its own value and whether inheritance is intentional.
The language switcher goes to a generic homepage
Use the actual localized entry URLs or the documented locales tag rather than guessing paths from prefixes.
A content item disappears from a listing
Inspect the collection’s site availability, the entry’s localized state and any frontend filtering by site.
The category is translated but the results are not
Test the taxonomy relationship and result query separately. Ensure the template retrieves the intended site’s entries.
A form works only in English
Check locale-specific labels, validation strings, handlers, success responses and actual service availability.
The same cached page appears in two languages
Inspect static cache configuration, host/path keys, rewrite rules and CDN behavior before editing translations.
A target page is discoverable before review
Review publish state, sitemap output, frontend visibility and search index jobs. Do not advertise an incomplete alternate.
A localized URL unexpectedly changes
Review the underlying slug, site handle, route and redirects. Treat renames as public URL changes requiring a migration plan.
A regional contact detail is wrong
Identify whether the value is inherited, shared or independently edited and confirm which service owns the actual address.
Arabic content is visually disordered
Check text-direction markup, mixed-script punctuation, form controls and component layout; do not reorder factual sequences.
A new source paragraph never reaches the translator
Add a source-change review handoff and compare content revisions. Do not overwrite a reviewed translation to force synchronization.
A practical four-week learning and rollout plan
Week one is for discovery. Inventory current collections, fields, global sets, navigation, taxonomies and essential journeys. Document who each site serves, what must remain shared, and what needs approved target-language content. Select a small pilot whose readers have a clear task. Establish an explicit fallback rule before changing configuration.
Week two is for modeling. Enable and configure a staging multi-site environment, add realistic test content, mark appropriate fields localizable and prepare language-aware Antlers or Blade templates. Check differences between inherited and overridden values. Deliberately test a missing translation and a locale-specific link rather than assuming all data is complete.
Week three is for editorial quality. Translate the pilot’s complete journey, including related resources, image descriptions, navigation, error messages and any downloadable materials. Ask independent readers to perform tasks in their own language. Fix content, route and accessibility defects separately, and recheck after changes.
Week four is for publishing. Run the URL, canonical, alternate-language, search, cache and form tests. Publish only reviewed variants and preserve an accountable change record. Monitor issues after launch, then extend to the next content family using the same tested workflow instead of starting anew each time.
Questions and answers
Is Statamic multi-site a free feature?
The official Statamic 6 documentation identifies multi-site as a Pro feature. Confirm the licensing terms of the installed version before planning a project around it.
Will turning on multi-site translate the website?
No. Multi-site makes site variants possible; translators, content owners and frontend templates still need to provide and verify the right text and reader journey.
What is the difference between locale and language?
Locale represents regional formatting preferences and environment behavior, while language settings can select the applicable language strings. Both should reflect real audience needs.
Should I localize every field?
No. Localize text and market-specific information where appropriate. Preserve stable machine keys and universal factual values unless the data model genuinely requires a distinct value.
Why does a translated entry show an English value?
It may be intentionally inheriting the source, a field may not be localizable, or the template may be fetching the wrong site. Diagnose which cause applies before changing data.
How do I build the language switcher?
Use actual localized entry destinations, such as the documented locales tag in Antlers where appropriate. Check that the target exists and is published.
Can a French site contain an English downloadable file?
Yes, if the file is relevant and honestly labeled. Do not imply that an English PDF has been translated merely by translating its link text.
Can one site serve multiple unrelated businesses?
The multi-site documentation describes related site variants and explicitly distinguishes the feature from a general multi-tenant system for unrelated projects.
What is the most common launch mistake?
Reviewing only the article body. Menus, related items, forms, cached pages and SEO annotations may still send visitors into the wrong language.
How do I prevent a bad translation from remaining in search?
Check public status, index updates, canonical and hreflang output, sitemaps and cache invalidation; correcting saved text alone may not update every search surface.
What should reviewers sign off on?
The source fact, target-language meaning, accessibility, direct URL, linked resources, service conditions and the actual rendered public page.
How should source changes be handled?
Classify their importance, identify affected variants, preserve approved target text and create explicit review work where a claim or instruction has changed.
Official documentation and further learning
The references below are the best starting point for configuration details. The feature set, plugin behavior and deployment environment of a real Statamic installation can differ from a tutorial example. Read the relevant version-specific instructions and verify every important assumption on a staging copy before changing production content.