You’ve just read a brilliant brief. The design looks clean. Then three weeks into development, the client asks: “Can we move the discount carousel above the hero?” Or worse: your backend editor can’t add a new product without breaking three other pages.
That happens because you started with design. Not with how to structure a website.
Structuring a website before touching design means mapping how content connects, repeats, and behaves, before a single button is placed in Figma. This article walks through a real project where ignoring structure led to two-month delays, and the exact process to avoid it.
What Most People Get Wrong About Website Structure
Most people think “structure” means a sitemap. A hierarchy of pages. Home → About → Services → Contact.
But that’s just the skeleton.
Direct answer: Website structure is how content types relate to each other, how they can be reused across different scenarios, and how easy they are to maintain by both developers and non-technical editors. If a button or a form can’t be repeated in some form in three different places without custom work every time, your structure failed.
In a real project with multi-country, multi-language requirements (specific products per country, region-based language switching), a simple page tree doesn’t work. You need relationships: a product belongs to a country, a region, a language variant, and a discount campaign, all at once.
The Real Mistake: Confusing Design Structure with Development Structure
Before we go into the step-by-step method, here’s a painful truth from a live project.
The situation: A large Typo3 website for international markets. The team decided to build everything from scratch, custom HTML, custom PHP, custom CSS. No Bootstrap. No framework. No repeatable patterns. Time we had? 3 months.
Why? Some developers argued that custom code gives “more control.”
What happened? It took 7 months and every new section took one to two weeks to build. Adding a simple product card or a marketing section required hand-coding the entire component. The backend relationships were never defined correctly first, so I struggled, others from the team struggled, editors struggled to reuse components content across the website.
The fix after the mistake: I’ve written a few php code functions to read data from Typo3 in json format, giving me more control over the outcome. It wasn’t the perfect solution because it was just a Band-Aid on the chaos, but it did the job. I also reintroduced Bootstrap. Yes, now the website had two css design systems, but timing was more important for the client than custom coding. Development time per section dropped from two weeks to three or four days.
The real lesson wasn’t just about Bootstrap. It was about planning from the repeatable patterns before writing any code.
The Step-by-Step Pre-Design Process (From a Real Project)
Here is exactly how to structure a website before touching design, based on what actually worked after multiple failures.
Step 1: Map use cases before drawing anything
Before opening Figma, Webflow, or even a whiteboard, write down every scenario where your content and functions needs to behave differently.
Direct answer: Brainstorm as many use cases as possible. For each scenario, ask: how complex would it be to adapt my structure to this? Find the repeating pattern that applies to all scenarios. That pattern becomes your structural foundation.
Real example from a multi-country project:
One scenario: A user in Germany sees a product in German, with local pricing.
Another scenario: A user in Switzerland (German-speaking region) sees the same product but with Swiss pricing and different shipping rules.
The repeating pattern: “Product belongs to one or more region-language combinations.” That pattern forced the backend structure before any frontend work.
Step 2: Write connections, not pages
Avoid the sitemap trap (Home → Category → Subcategory). Instead, write down how each piece of content connects to another.
Method from the field:
- Take a sheet of paper or a note-taking app.
- List each content type: Product, Article, Discount, Region, Language.
- Draw lines between them. Label each line with a requirement (e.g., “Product ─requires price in local currency─→ Region”).
Only after those connections are clear do you move to a wireframe. And even then, it’s an ugly wireframe, just boxes pointing to the simplest possible user flow.
Step 3: Simplify to 3–4 common elements
This is where most planners fail. They create a beautiful, unique structure for every page. Then maintenance becomes a nightmare.
Direct answer: After mapping connections, find the 3–4 common elements that appear across 80% of your use cases. Build your entire site structure around exactly those elements. If a new page requires a fifth element, question whether you really need that page.
Real example:
A news website had 12 different article templates. The common elements were: headline, body text, author, and publish date. Everything else (galleries, sidebars, related links) was made optional, not a separate structure. That cut development time by half.
Step 4: Choose the simplest possible implementation path
Once your content structure is defined, choose tools and frameworks that preserve that structure, not fight against it.
What not to do (from a real mistake):
The team rejected Bootstrap because “we want more control.” That led to custom-coded components that were hard to be reused. The structure broke under its own weight. Pressure and timing were against our custom coded approach.
What to do instead:
Pick a framework (Bootstrap, Tailwind, or even a CMS-native builder like Bricks) that allows you to turn your 3–4 common elements into repeatable blocks. Name those blocks clearly in the backend so your client can edit without breaking relationships.
Before → After: A Real Structural Fix
| Before (bad structure) | After (good structure) |
| Three product carousels, each custom-coded | One product block reused via a “discount tag” condition |
| Editors duplicate products for each country | Product connected to region-language table, shown automatically |
| New section = 2 weeks of coding | New section = 3–4 days (most of that is content entry) |
| Team argues about menu positions | Structure defines where products can appear based on type |
The turning point was not a design change. It was a structural change: defining relationships first, then building repeatable components.
Where AI Helps (and Where It Hurts) in Structuring Websites
Where AI is useful:
- Brainstorming structural alternatives. “What are five ways to organize products by region and language?”
- Finding repeating patterns across use cases. Feed AI your scenario list and ask: “What are the 3–4 common elements here?”
- Generating initial connection maps from a brief.
Where to avoid AI:
- Final decision-making on hierarchy. AI doesn’t know your client’s internal politics or which department head will demand a top-level menu spot.
- Writing actual content models for the backend. AI often suggests elegant but impractical relationships that your CMS can’t handle.
Direct answer: Use AI as a brainstorming partner for structure, but always validate its output against real editorial workflows. The person who will add 500 products next month cares more about “does this block repeat cleanly” than about theoretical elegance.
What Would I Do Differently Today?
After multiple failures (custom code without a framework, unclear structural goals, team disagreements mid-build), here is the process I follow now:
- Understand the real problem – not the requested feature, but the underlying need.
- List every use case – including edge cases like “what if we add a new country next year?”
- Find the repeating pattern – usually 3–4 common elements.
- Map connections on paper – no software in the first steps.
- Build an ugly wireframe – just boxes and arrows, no colors or fonts.
- Validate with the editor – “Can you add a new product to multiple regions without calling me?”
- Choose the simplest framework – existing tools that support your structure.
- Then open Figma or a builder.
The biggest change: I never let multiple team members decide structure simultaneously without a single, written goal. Every debate about menu placement, section order, or backend structure gets settled by the use-case list, not by opinion.
Summary: How to Structure a Website Before Touching Design
- Structure is not a sitemap. It’s how content types connect, repeat, and behave across scenarios.
- Start with use cases, not pages. Find the repeating pattern across all scenarios.
- Simplify to 3–4 common elements. Everything else is optional decoration.
- Map connections on paper first. Then ugly wireframes, then design, then code.
- Use AI to brainstorm, not to decide. Real editorial workflows matter more.
- Pick frameworks that preserve your structure. Custom code without a plan creates debt.
Design is what users see. Structure is what survives three years of content updates, five new team members, and one inevitable request to “just move that section up a bit.”
Get the structure right first. The design will follow, without the midnight panic.