30.1 Public Website Architecture

AIUNIFY Leads separates the authenticated Website-management workspace from the public Website experience viewed by visitors.

The public routing system resolves a Website using its configured Website Slug and the Website route prefix defined by the application configuration.

30.2 Do Not Hard-Code the Website Route Prefix

The Website route prefix is obtained from Company settings through the application's website_route_prefix configuration.

Because that prefix is configurable, users should rely on the generated Landing Page URL instead of manually constructing public URLs from assumptions.

30.3 Website Home Page

The normal Website landing route locates the Website by its Slug and presents the Website using the page key:

home

This is why the Home Website Page is a foundational page in the Website structure.

30.4 Custom Website Pages

Public custom Website Pages use their saved Page Key.

Before rendering a requested Page Key, AIUNIFY Leads verifies that the Page belongs to the requested Website.

If the requested Page Key does not exist for that Website, the public route returns a not-found response instead of displaying a page belonging to another Website.

30.5 Website Legal Pages

Website Legal Pages use a separate public page route from ordinary Website Pages.

The route resolves:

1. The Website Slug.
2. The Legal Page Slug.
3. The applicable Website Language context.

Use the Page URL supplied by Website Legal Pages rather than manually guessing this route.

30.6 Theme Selection

The public Website obtains its Theme from the Website record's Theme Name.

If no Theme Name is available, the confirmed routing logic falls back to:

tailwind_theme

30.7 Public Website Data

Before rendering a public Website route, AIUNIFY Leads prepares and shares the Website information required by the selected theme.

This includes the resolved:

1. Website.
2. Website Settings.
3. Theme Name.
4. Website Slug.
5. Language Key.
6. Language identifier.

30.8 Public Language Resolution

AIUNIFY Leads uses several mechanisms to determine which Website Language should be displayed.

For public routes that support an explicit language query, the confirmed resolution sequence is:

1. A valid supported Language supplied through the applicable lang query parameter.
2. The Website-specific visitor language cookie.
3. The Website's configured Default language.
4. English when an English Website Language exists.
5. The first Website Language available for that Website.
6. An English language-key fallback when no language record resolves.

30.9 Language Query Parameters

The confirmed public Legal/Static Page route enables explicit query-language checking.

The ordinary Website landing route and ordinary custom Website Page route do not enable that same query-language check in the routing helper.

For normal Website browsing, the Website-specific language cookie and Default-language behavior are therefore particularly important.

30.10 Website-Specific Language Cookie

The public Website uses a Website-specific cookie naming pattern:

lang_{website-slug}

This allows different Websites to maintain separate visitor language selections.

30.11 Effect of Changing the Website Slug

Because the Website Slug participates in both the public URL and the language-cookie name, changing the Slug can affect:

1. The Website's public URL.
2. Previously distributed links.
3. The Website-specific language-cookie context.

Review the complete public Website after changing a Slug.

30.12 Website Settings by Language

After the public Language is resolved, AIUNIFY Leads looks for Website Settings associated with that Website and Website Language.

This allows Website identity, SEO, contact, and related settings to vary between languages.

30.13 English Website Settings Fallback

If a non-English visitor Language is selected but no corresponding Website Settings record exists, the confirmed public-routing logic attempts to use the Website's English Website Settings.

Best practice: Complete Website Settings for each Website Language you intend to use publicly rather than depending on fallback behavior.

30.14 Selected Website and Primary Website Are Different

The Website selected inside the administrative workspace determines which Website is currently being managed.

The Primary Website is a separate setting used by applicable non-SaaS public root-routing behavior.

Changing the selected working Website does not automatically change which Website is Primary.

30.15 Current Root URL Behavior

In the current confirmed routing implementation, the bare application root redirects to:

/admin/login

This occurs even in the routing branch where a Primary Website exists.

At the same time, the non-SaaS routing code contains root-level custom Page and Legal Page handling for the Primary Website.

Operational guidance: Use the generated Landing Page URL when validating and distributing a Website rather than assuming the bare application domain is the Website Home page.

30.16 Section Layout Preview Route

The application contains a dedicated Section Layout Preview route used by the administrative Website Builder.

When a Website is supplied to that preview, the system can use the Website's Theme Name while rendering the section-layout example.

This is an administrative design aid and should not be confused with the final public Website URL.

30.17 Public Page Troubleshooting

If a public Website Page does not display as expected, verify:

1. The Website Slug.
2. The Page Key for an ordinary Website Page.
3. The Legal Page Slug for a Legal Page.
4. The Website Language configuration.
5. The Default Language.
6. The Website Settings for that language.
7. The Theme Name.
8. The Website Builder sections for the requested Page and Language.

30.18 Recommended Public-Site Validation

1. Open the generated Landing Page URL.
2. Verify the Home page.
3. Open every important custom Website Page.
4. Open each Legal Page through its Page URL.
5. Test the Default Website Language.
6. Test every additional Website Language.
7. Verify Website Settings are correct for each Language.
8. Verify Header and Footer navigation.
9. Verify Theme presentation.
10. Repeat after changing the Website Slug, Default Language, Theme, or major Website Builder structure.