Website architecture: why your site keeps growing but stops delivering results

Every new page seems justified when it is created. The launch campaign called for a landing page, the sales team wanted a page for the new service, HR needed a space for job openings, and every request was delivered on time.

Two or three years later, the site is twice the size, the menu has picked up items nobody remembers approving, and renaming a service means hunting for the term across dozens of pages.

The problem rarely lies in a single page. It shows up in the sum of decisions made without shared rules about what goes on the site, where it lives, and how it connects to everything else.

Without those rules, the site loses results in three ways: visitors take longer to find what they need, information becomes inconsistent across pages, and the team spends on rework the time that should go into improvements.

Website architecture is the work of defining those rules. This guide shows how to recognize when the structure has become a bottleneck, what good organization solves, and how to restructure the site without losing what currently brings in traffic and opportunities.

When a website grows and becomes harder to use and update

The warning signs show up in internal conversations before they reach the reports. On mid-size and large corporate websites, four situations come up again and again:

• Visitors can’t find the service by the name they know: the offering exists, but it is scattered across business unit pages, each with a different label;

• Every campaign starts from scratch: without page templates and reusable blocks, marketing depends on developers to publish a landing page similar to the last one;

• The same information lives in several places: the number of clients, a branch address, or a product description appears on ten pages, and the correction only reaches seven;

• Nobody knows what can be taken down: pages for past events and discontinued services stay live because there is no record of who owns them.

For visitors, the effect is a longer, less reliable path to a decision. A B2B buyer comparing vendors runs into conflicting information and has to piece together, on their own, how the service relates to the company’s experience in their industry and the results it has already delivered. For the team, every small adjustment eats up hours of searching, reviewing, and reworking, and the site starts to be seen as an obstacle to campaigns when it should be supporting them.

What is website architecture and how does it affect results?

Website architecture is the way a site’s content is organized: which pages exist, how they are grouped, what they are called, which level they sit on, and which paths visitors and search engines take to reach each one. It should come before the layout and stay in force after it, because it guides every new page added to the site.

Three terms often get mixed up in conversations about the topic. Separating them helps pinpoint where the problem lies:

Nielsen Norman Group, a leading usability research firm, treats information architecture and navigation as different things: the first is the foundation that organizes the content, and the second is the layer the user sees. The distinction explains why a menu redesign without a review of the organization behind it usually changes how the site looks while leaving visitors with the same questions.

For the business, website structure affects three moments in the journey: finding the right information, understanding how one offering relates to the others, and moving to the next step, whether that is a contact request, a quote, or a downloadable resource.

It does not drive conversion on its own. Offer, pricing, content clarity, page experience, and traffic quality also weigh on the decision. Good architecture will not save a weak value proposition, but a confusing structure wastes visits from people who arrived on the site ready to buy.

How can you tell if the structure is getting in the way of the user journey?

A structure with problems leaves traces in three places: navigation data, published content, and people’s behavior. None of them settles the diagnosis alone. The most useful signals appear when the three sources are cross-referenced.

Metrics in isolation are misleading. A high bounce rate on the contact page may mean the visitor found the phone number and called, and a long time on a service page may signal interest or confusion. Data shows what happened, the inventory shows what exists, and user testing helps explain why.

In an expert-led diagnosis, the most common starting point is the content inventory: a spreadsheet listing every URL, the type of each page, its owner, the last update date, traffic, inbound links, and conversions. With that map, it becomes clear what drives results, what is duplicated, and what nobody has visited in years. User testing comes next, to confirm whether the proposed groupings and labels make sense to buyers.

The patterns that make corporate websites disorganized

Few websites become disorganized through carelessness. They grow by fulfilling legitimate requests, one at a time, with no criteria that look at the whole. Four patterns come up often.

Requests evaluated one at a time

Each department asks for the page it needs, and the question usually asked is whether the request fits the deadline. The missing question is whether the site already has a page that meets that need, or whether the new one will compete with an existing page. Without it, the site piles up similar versions of the same content.

Menus that mirror the org chart

Many corporate menus follow the company’s internal structure. Items are named after departments, business units, or product lines, because that is how teams see themselves from the inside.

Visitors don’t know that structure. They arrive with a problem to solve and look for it. If a manufacturer splits its menu into “Agribusiness Division” and “Industrial Division,” a buyer looking for a maintenance service has to guess which of the two offers it.

The mistake is old and well documented. The book Web Bloopers, by Jeff Johnson, published in 2003, already listed it among the most common usability problems on websites. 

“One of the most common problems in corporate website architecture is organizing the menu around the company’s internal structure instead of the logic of the people using the site. Understanding how people look for information makes it possible to build more intuitive navigation, with paths that make sense to the user. ” - Rafael Andrighetti, Head of Design at Dexa

Campaigns outside the structure

Campaign landing pages are built in a hurry, outside the site’s templates and without links to related services. When the campaign ends, the page stays live with no owner, competing with permanent pages or sending visitors to an offer that has expired.

Nobody decides what gets removed

When no one has the authority to consolidate or remove pages, the site only grows. Content governance is the agreement on who decides and by what criteria. A simple model cuts down much of the buildup:

When creating a page, assign an owner and a review date. When consolidating, merge the content into the strongest page and redirect the other with a 301. When removing, use a 301 if there is an equivalent page; otherwise, return a 404 or 410. Pages that stay live also need periodic review.

The elements of a website’s structure and what each one does

Each element of the structure answers a different question for visitors and search engines. Treating them by function avoids decisions driven by taste or habit.

Google’s official recommendations follow the same logic. Its SEO Starter Guide suggests descriptive URLs and grouping pages on similar topics into directories. Its documentation on links explains that the search engine uses links to find new pages and assess the relevance of each one, and it asks for descriptive anchor text. 

On sitemaps, Google’s guidance is direct: when pages are well linked, the search engine generally discovers most of the site. The sitemap complements internal links but does not replace a well-connected structure.

Flat or deep structure: which works better?

Every site structure balances two forces: showing many options at once or spreading content across several levels. In a flat structure, the menu displays more items and visitors reach what they need in a few clicks.

In a deep structure, the menu is leaner, but specific content sits a few levels down. It can accommodate large sites, but every extra click increases the chance that visitors get lost or give up along the way.

According to Nielsen Norman Group, neither model is better by definition. Flat structures work when categories are clear and easy to recognize. Intermediate levels help when visitors need context before choosing.

The starting point for the decision is the content. A company with twelve services that buyers know by name can list them directly in the menu. A portfolio of eighty technical solutions works better with needs-based categories, shortcuts to the most requested items, and breadcrumbs that show visitors where they are.

Topic groupings: topic clusters and hub and spoke

Both models follow the same logic: a central page covers the topic and links to pages that go deeper into each part of it, which in turn point back to the center. The name changes depending on the context.

Topic cluster is the more common term in content and SEO, with a pillar page linked to supporting articles. Hub and spoke shows up more often in the organization of site sections, with one page serving as the starting point for the others.

On a corporate website, the page for an industrial maintenance service can be the hub. From it, links lead to the industries served, the service’s case studies, and articles on maintenance planning, and each of those pages takes visitors back to the service.

The model works when the topic has real depth and real demand. Applied by formula, it produces supporting pages nobody searches for and links nobody clicks. The article on SEO for businesses shows how these groupings build a site’s authority.

From standalone pages to a content system

When a site is assembled from standalone parts, the same case study is copied onto the service page, the industry page, and a campaign page. If the client asks for a correction, someone has to remember where all the copies are.

In a content system, information is entered once and appears wherever it makes sense. That depends on two layers:

• Content types define what the information is. The “Case study” type has fields such as client, industry, service, and result. This work is called content modeling;

• Interface components define how it appears. The same case study becomes a card on the service page and a highlight on the industry page.

As a result, a case study tagged with the service and the industry shows up on both pages automatically, and a correction made once reaches every location. The same applies to FAQs, comparisons, and materials that support the buying decision.

Marketing builds campaigns from pre-approved components, without relying on developers for every page. Visitors find the service, the industry, and proof of results linked together.

On the Cemig Saúde portal, Dexa replaced a proprietary tool with an open platform and a Design System integrated into the CMS. After the change, the time to publish new pages dropped by 70%, and front-end and repetitive development costs fell by 50%.

This model requires a CMS that supports content types, fields, and relationships, such as Drupal. The article on the CMS as a strategic pillar can help with that choice.

How do you restructure a website without losing what already works?

Restructuring doesn’t mean wiping the site and starting over. Pages that currently earn visits, backlinks, conversions, or citations in AI-generated answers carry a history that has to be transferred carefully. A well-run restructuring process goes through six stages:

1. Diagnosis. Cross-referencing navigation data, Search Console, site search, and interviews with the teams that publish on the site to understand where the structure is holding back the journey and day-to-day operations.

2. Inventory. A complete list of URLs with type, owner, traffic, inbound links, and conversions. This is the stage where you decide what stays, what gets consolidated, and what goes.

3. Architecture proposal. New hierarchy, labels, content types, components, and URL pattern, documented in a sitemap and a content model.

4. Validation. Card sorting and tree testing with people from the target audience, plus a review with the internal teams that will maintain the content.

5. Implementation. Mapping each old URL to its new equivalent, setting up permanent (301) redirects, updating internal links so they point directly to the final destination, and updating the sitemap.

6. Monitoring. Tracking crawling, indexing, traffic, and conversions over the following weeks, with quick fixes for 404 errors and redirect chains.

On the technical side, Google’s documentation on URL changes recommends preparing the URL mapping before touching the server, using permanent redirects, and keeping them in place for as long as possible, generally at least a year. The search engine processes the move URL by URL, and medium-sized sites can take a few weeks before most pages are updated in the index. Dexa’s SEO migration guide covers these precautions in detail.

Restructuring also doesn’t require switching CMSs or rebuilding the entire site. In many projects, the fastest gains come from reorganizing the menu, consolidating duplicate pages, creating campaign templates, and strengthening the links between services, industries, and case studies. A platform change comes into the discussion when the current tool prevents the content modeling or governance the site requires. That scenario calls for its own precautions, covered in the article on CMS migration.

How do website architecture, SEO, and AI answers relate?

Search engines and AI systems depend on the same foundation: finding pages, understanding what each one is about, and trusting the information. Three different stages are often confused:

Website architecture acts directly on the first two stages. A page with no internal links that is missing from the sitemap can take a while to be found. Duplicate pages force the search engine to choose which version to show.

The third stage depends on other factors, such as content clarity and brand reputation. No structure guarantees that a page will be cited.

This is where two acronyms come in. AEO (Answer Engine Optimization) structures content to answer questions directly. GEO (Generative Engine Optimization) focuses on systems that generate answers with AI, such as ChatGPT, Gemini, and Google’s AI Mode.

According to Google’s guide to AI features, there are no extra requirements to appear in these results: the page has to be indexed and eligible to show a snippet. SEO best practices still apply.

Structure helps in three ways:

• One page per topic, so the search engine doesn’t have to choose between similar versions.

• Descriptive internal links that show how services, industries, and case studies relate.

• Consistent information, with the same names, industries, and data across every page.

The article SEO vs. GEO explains what changes when optimizing for AI-powered search.

How Dexa supports the growth of corporate websites

Dexa has worked in digital experience since 2002. To organize a website’s growth, three of the company’s practice areas work together:

• Experience Design: websites, web apps, and digital products with strategic UX and a Design System, to reduce rework and keep the brand consistent. The article on UX consulting goes deeper into this area.

• Enterprise Technology: development, migration, and evolution of CMS, DXP, and Drupal platforms, with editorial autonomy and Managed Services to monitor and update operations.

• Digital Growth: SEO, GEO, content, and data to help the brand gain relevance in search engines and AI answers.

The combination matters because website architecture cuts across all three areas: it starts in design, depends on the platform to work, and requires SEO follow-up after launch.

The Design System and editorial autonomy support the content system described in this article: ready-made components for building pages and a CMS that marketing updates without depending on developers.