How connectrader websites are structured

A connectrader website is usually built as a small software system, not as a collection of independent pages. That distinction matters more after launch than it does on launch day. Almost any tool can produce ten pages that look correct once. The architecture starts to matter when the business adds another service, another market, another article library, new analytics, a new form workflow, a redesign, a migration, or a second developer.

Our goal is to make those later changes predictable.

We separate page types from page instances

A service is a page type. A location is a page type. An article is a page type. A case study is a page type. Documentation is a page type. When a type repeats, we normally build one route family and supply it with different content.

That is why many of our repos contain routes such as /services/[slug], /locations/[slug], or /blog/[slug]. The route owns the shared behavior. The content object owns what makes the individual page different. This is explained in more depth in Why we build route families instead of copying pages.

Content is usually source-controlled

For managed business websites, we often keep long-form content in MDX or structured source files. A server-side loader reads the file, separates frontmatter from the body, normalizes fields, resolves images, and returns a stable content model to the route. This gives us a clean editorial surface without requiring a database or CMS runtime for every page view.

It also means content changes live in the same release history as code changes. Read Why our website content usually lives in the repository for the reasoning behind that choice.

The application layer owns behavior

Content should not decide how a mobile menu works. An MDX file should not decide canonical behavior. A service description should not have to know how schema is serialized. Those concerns belong in application code. The route and component layers own things such as:

• navigation
• layout
• responsive behavior
• structured data
• metadata
• forms
• interactive state
• image rendering rules
• accessibility behavior

The content layer owns the business-specific information. That separation is what lets us change presentation without rewriting every document.

Server rendering is the default for information

Most public website content does not need browser-side state. We prefer to render it on the server or generate it ahead of time. The browser receives meaningful HTML, then interactive features enhance the page where needed. A gallery may need client-side state.

A dialog may need client-side state. A navigation drawer may need client-side state. The service description above those features does not. That is the core of our server-first architecture.

Shared components are not only a code-quality preference

A shared component turns repeated behavior into one maintained system. If the footer needs an accessibility fix, one component is better than twenty copied footers. If the navigation needs a mobile correction, the fix should not be reproduced across page files. If a related-content card changes, all pages using the card should inherit the improvement.

This reduces drift. It also gives QA more leverage because testing the shared implementation improves confidence across every route that uses it.

Metadata is infrastructure

Titles, descriptions, canonicals, social images, article fields, robots behavior, and structured data repeat across the site. Several of our production repos centralize this logic in helper functions rather than rebuilding it in each route. The page supplies what is unique. The helper supplies the site-wide policy.

That is covered in Why we centralize page metadata.

The sitemap comes from the same system

We do not want the public sitemap to become a separate list that drifts away from the application. The sitemap can be generated from the same service, location, article, portfolio, and documentation registries that power the routes. If a valid content item exists, the route system knows about it.

The sitemap can know about it too. This keeps the public crawl map tied to the actual site architecture.

Last modified dates come from real changes

Our repository history already records when source files change. Several of our sites use that history to generate sitemap modification dates instead of stamping every route with the date of the latest deployment. A footer edit should not pretend that every article was revised.

The reasoning is documented in Why lastmod should come from real source history.

Preview and production are intentionally different

The same codebase can run in a review environment and in production, but those environments do not have the same role. Preview exists to test changes. Production is the public source of truth. That affects indexing, environment variables, analytics, forms, and review expectations.

We make that distinction explicit rather than treating every deployment URL as equally public. See Why preview and production are treated as different systems.

The repository should be understandable without the original developer

This is one of our stronger architectural tests. Can another competent developer find the route, content source, shared component, metadata logic, form boundary, and deployment assumptions without reverse engineering the entire project? If not, the project is too dependent on tribal knowledge.

We prefer obvious file structure, clear loaders, narrow responsibilities, and boring naming over clever abstractions that save a few lines but make the system harder to inherit.

The architecture changes with the product

A brochure site and a web application should not have identical infrastructure. A marketing site may need no database at all. An application with accounts and durable workflows obviously does. A simple site may have no route handlers. A gated resource or webhook may justify a small server boundary.

We do not force every project into the same stack diagram. We reuse the principles that remain useful:

• keep the content model explicit
• keep runtime work proportional to the feature
• keep public routes predictable
• keep shared behavior shared
• keep deployment reproducible
• keep ownership portable

The result is not the most complicated architecture we could build. It is the smallest architecture that still gives the business room to grow.