App Router architecture for service websites

A service website is not only a set of sections. It is a set of promises that search engines, prospects, and internal teams need to find again later. The App Router works well when the route tree mirrors those promises.

For a portfolio or agency site, that usually means a stable home page, service pages, case studies, blog posts, and a contact path. The route names should be readable without context because they will show up in analytics, links, and search snippets.

The page that owns a search result should also own the title, description, canonical URL, and structured data. Splitting those concerns across distant helpers makes SEO changes slower and easier to miss.

Shared data files are still useful. The clean split is simple: reusable content belongs in data, route-specific SEO belongs in the route file.

Most service pages are reading experiences. They do not need client state for every card, badge, and heading. Server components keep the shipped JavaScript smaller and make the page easier to reason about.

Client components should be reserved for real interaction: menus, filters that need instant local state, animations, forms, and measured browser APIs.

A strong blog system starts with article shape: slug, title, summary, category, tags, highlights, and sections. Once the content has structure, the UI can switch between index cards, reading pages, topic filters, and related posts without rewriting copy.

This matters on small portfolios because the same article may need to support SEO, hiring conversations, proposal links, and social previews.