SEO and website architecture: the blueprint before you build

A website should not begin with design or a list of keywords. Learn how to connect your business, demand and your customers’ needs to define which pages you need, how to organise them and what each one should do.

Imagine you are going to build a house.

Before choosing materials, arranging furniture or deciding on finishes, you need to understand how the space will be used.

How many people will live there, what they need, how the rooms will connect and what requirements the building must meet.

Then you will need a blueprint.

Something similar should happen with a website.

Yet many projects begin directly with design.

A template is chosen, the homepage is drawn up and a menu is organised around the usual sections: Home, Services, About and Contact.

The available content is then distributed and, once the website already has a defined structure, it is time to work on SEO.

That is when difficulties can emerge.

We discover that different services need their own pages, that some important searches do not receive a suitable answer or that several pages explain almost the same thing.

Sometimes we need to redo part of the work. Other times we accept an unsuitable structure because changing it would take too much effort.

The problem does not necessarily lie in the design or the quality of development.

It lies in having started building before deciding what we needed to build.

Website architecture helps resolve that question.

It connects the reality of the business, its offering, people’s needs and search demand with a coherent structure of pages, content and journeys.

It is more than drawing a menu.

It means creating the blueprint that design, content, development and SEO can work from.

The clearer that blueprint, the easier it becomes to build a website that serves a real purpose for the business.

1. What website architecture is and why it matters

Website architecture is the organisation of a site’s information, pages and functions, together with the relationships between them.

It helps determine which content needs its own space, how it is grouped, the importance of each section and how people can find what they need.

It also helps search engines discover pages and better understand their relationships.

But its value extends beyond search rankings.

Good architecture makes it easier for someone to find their way around a website, understand an offering, compare alternatives and take the action they need.

Consider a small hotel.

One person may arrive looking for information about its rooms.

Another wants to know the conditions for staying with children.

A third needs to check availability for specific dates.

Someone who does not yet know the establishment may be researching the experiences the destination offers.

Not all these needs necessarily require a separate page.

But they all deserve a suitable answer.

Architecture should help us decide where to provide that answer and how to connect it with the rest of the site.

A page needs a reason to exist

A page should not be created simply because we need another menu option.

It should serve a recognisable purpose.

It may present a service, answer a question, support a purchase, demonstrate experience, explain terms or help people find related information.

Some pages serve commercial purposes.

Others provide information, support operations or build trust.

What matters is knowing which need each one addresses.

For example, a service page may explain an activity and help people book it.

An article may help them understand how to choose that activity.

A general page may organise different experiences so visitors can find the most suitable one.

The three serve different purposes, but can work together.

Good architecture does not seek to accumulate pages. It seeks to organise answers.

Architecture is not the navigation menu

This distinction matters.

Architecture defines how the website’s information is organised.

Navigation is the set of mechanisms that provide access to it: menus, links, categories, filters and other elements.

A website can contain dozens of pages without including all of them in its main menu.

It can also have a visually simple menu with complex architecture behind it.

Nielsen Norman Group makes this distinction between the organisation of content and functionality and the navigation elements that help people find them. [1]

Designing a menu therefore does not amount to designing the architecture.

First we need to understand which information should exist and how it relates.

Then we can decide how to make it accessible.

2. Why SEO and website architecture should work together

SEO, or search engine optimisation, aims to improve a site’s ability to be discovered through searches relevant to its content and objectives.

A fundamental part of this work is researching what people search for and what they expect to find.

Architecture uses that knowledge to organise pages and their relationships.

The two disciplines should therefore develop together.

But we need to establish an important distinction:

SEO provides evidence about demand. It should not replace business strategy.

First we understand what the company offers

Imagine a company specialising in guided excursions in the Pyrenees.

Its proposition centres on small groups, professional guidance and experiences adapted to different fitness levels.

During SEO research, we discover interest in mountain equipment hire.

Does that mean we should immediately create a page for that service?

Not necessarily.

First we need to check whether the company offers hire, wants to develop it and has the resources to do it properly.

A search can represent an opportunity.

But it may also fall outside our business model.

Creating content to attract people interested in services we do not offer can increase visits without delivering commercial value.

That is why digital strategy must establish an initial scope.

We need to understand what the business offers, whom it wants to serve, which territories it covers, its capabilities and its objectives.

Then we use SEO to research how that demand is expressed and test our assumptions.

Then we research how people search

Customers do not always use the same language as the company.

A business may describe its product as “assisted cycle touring experiences”.

Its customers might instead search for “electric bike routes” or “guided e-bike excursions”.

These expressions may refer to related services, but we need to check the intention behind each one.

One person may want to book an excursion.

Another is looking to hire a bicycle.

A third simply wants to find a route they can follow independently.

The words may look similar.

The needs are different.

Search research helps us recognise these nuances and decide which answers the website should provide.

Search volume does not decide for us

A keyword with many searches is not automatically an attractive opportunity.

We must assess its relationship with our offering, user expectations, existing competition and our ability to provide a useful answer.

We must also consider lower-volume searches that may represent a much more specific and relevant need.

For a specialist business, attracting fewer people who are better aligned with its proposition may make more sense than pursuing large volumes of traffic with little connection to its services.

This is not a choice between strategy and SEO.

It is about using them together.

The business establishes the value it can offer. Demand research helps us understand where and how that value may be relevant.

Google also recommends organising sites logically to help both users and search engines understand relationships between pages. [2]

3. How a website’s blueprint is built

At PhiStudio, we organise SEO and architecture around five connected tools.

Each answers a different question and helps move from business knowledge to a structure ready to build.

This sequence is our way of organising professional work.

It is not a mandatory universal methodology. In practice, the findings from one stage can lead us to revisit earlier decisions.

1. Initial functional sitemap: the first hypothesis

The first step is proposing which pages the business might need based on its strategy and offering.

We are not yet deciding the final structure.

We are forming a hypothesis.

For example, if a company offers three genuinely distinct services, we may initially consider one page for each.

If it serves different territories, we must investigate whether those differences justify specific content.

If it has information resources, we need to understand their role within the whole.

The result is an initial map of possible pages.

This map gives us a business reference from which to begin research.

But it can still change.

A page initially envisaged may prove unnecessary.

Or we may discover an important need we had not considered.

This functional sitemap should not be confused with the XML sitemap used in technical SEO.

The former is a planning tool, but a page diagram does not cover every architecture decision. [3]

The latter is a file that gives search engines information about the site’s URLs we want to help them discover. Its existence does not guarantee that all those pages will be crawled or indexed. [4]

2. Demand research: testing against the market

We now need to check how people search for the services, products or knowledge related to our business.

We can use SEO research tools, information from actual searches, data from the existing website and the knowledge gained through direct contact with customers.

The purpose is not to accumulate thousands of keywords.

It is to understand which needs emerge, how they are expressed and which opportunities may be relevant.

Research may also reveal territorial differences, variations in language or queries we had not initially considered.

But we must interpret these data carefully.

The same expression can have several meanings, and high volume alone does not demonstrate an intention to buy.

We also need to observe which types of results appear for the queries researched.

If a search mainly returns guides and route maps, users may expect information to organise an excursion themselves.

If pages from companies offering guided experiences predominate, commercial intent may be different.

These observations do not replace thorough research, but provide context.

3. Intent map: understanding which answer is needed

Once relevant searches have been identified, we must understand what each person is trying to achieve.

Some want to learn.

Others want to compare alternatives.

Some are looking to locate a service, understand its terms or make a booking.

Search intent helps us decide which kind of answer to prepare.

For example:

“How difficult is an electric bike route” may represent an information need.

“Guided e-bike excursion Val d’Aran” may express interest in a specific service.

“Book guided electric bike route” signals a more explicit booking intention.

But these classifications are initial hypotheses.

We must test them against search results, the offering and actual user behaviour when information becomes available.

What matters is understanding that not every query needs the same content.

Good architecture should provide suitable answers for different customer situations.

4. SEOMap: deciding which page will answer

The SEOMap is the tool we use to organise search groups, their intentions and the pages that should address them.

Its main purpose is to prevent us from building a website as an accumulation of disconnected content.

We may find several expressions representing almost the same need.

In that case, a single well-developed page may answer them adequately.

We may also identify different needs that deserve separate pages.

The SEOMap lets us assign a main page responsible for each group of intentions and establish which other pages can support or complement it.

It is important not to confuse this thematic responsibility with technical canonicalisation.

In SEO, a canonical URL is the version Google selects as representative when it identifies duplicate or very similar pages. We can communicate a preference through mechanisms such as rel="canonical", but Google makes its own decision. [5]

Assigning a main page to a search intent is an architecture and content decision, not a technical canonicalisation instruction.

This distinction allows us to use each concept correctly.

5. Final architecture: organising the complete system

With the strategy, research and SEOMap decisions, we can consolidate the structure.

We now define which pages the website will contain, their functions and their relationships.

We can also establish their addresses, hierarchies, main navigation, content groupings and relevant internal links.

At this point we distinguish between different levels:

Architecture establishes the conceptual organisation of information.

Navigation helps people find pages.

URLs identify published addresses.

Internal linking connects related content and enables journeys between it.

These elements should be coherent, but they are not identical.

For example, a page can belong to the activities area without necessarily needing a URL with several folder levels.

What matters is that the structure is understandable and the addresses clear and maintainable.

We can now represent the whole through a blueprint that will guide subsequent stages.

But an important question remains:

How does all this work translate into an actual website?

Let us look at an example.

4. Practical example: designing architecture for a mountain experiences company

Imagine a small company in the Val d’Aran organising guided excursions and nature activities.

Its current website has a simple structure:

Home · Activities · About · Contact

The Activities page presents all services through photographs, short texts and several contact buttons.

The company wants to renew the website because it feels its experiences are not sufficiently differentiated and information about each is difficult to find.

Its first idea is to modernise the design.

But first we need to check whether the current structure properly addresses the needs of the business and its customers.

This example is entirely illustrative. The searches, offering and proposed decisions do not come from actual research or represent results from a PhiStudio project.

Step 1. We understand the offering and objectives

During analysis we identify two main lines:

Guided hiking. Professionally accompanied excursions with different routes and difficulty levels.

Guided electric bike routes. Organised experiences to discover the area on electric bicycles.

The company also organises some private group outings.

However, we do not yet know whether these private experiences justify a separate commercial line or simply represent a booking option for the main activities.

That is a question we need to investigate.

We also need to know the business objectives.

Suppose the company wants to increase direct bookings and reduce the time spent repeatedly answering the same questions.

This means the architecture must fulfil two functions.

First, help people discover and understand the experiences.

Second, make it easier for customers to find enough information to decide and book.

We now have a much more precise starting point than “we need a modern website”.

Step 2. We build the first page map

Based on the offering, we could propose an initial structure:

This first map comes from the business.

We have not yet researched demand sufficiently.

We should therefore not consider it final.

It is a hypothesis we will test.

Step 3. We research relevant searches

We now analyse how interested people might search for these experiences.

For example:

These expressions are research examples, not validated keywords.

We are not claiming that all have significant demand or should be incorporated into the website.

We must check them against tools and search results.

Some may also express different needs.

For example, someone searching for “e-bike routes Val d’Aran” may be trying to find itineraries to follow independently.

But our company offers guided excursions.

That means we need to check whether the search actually fits our offering.

It would make no sense to promise self-guided routes or bike hire if those services do not exist.

Step 4. We group the intentions

After researching queries and comparing them with the offering, we can begin organising needs.

Imagine we find four relevant groups.

Group A. People looking for guided hiking excursions.

They need to understand which routes are offered, how long they take, their difficulty and how to book.

Group B. People interested in guided electric bike experiences.

They want to know the activity’s characteristics, requirements and availability.

Group C. Families who need to check whether an activity is suitable for their children.

Their questions may arise in both hiking and cycling contexts.

Group D. People who want information about routes and activities before deciding what to do at the destination.

They may need informative content that does not involve an immediate booking.

These groups do not automatically have to become four pages.

First we need to check which answers they share and which require their own explanation.

Step 5. We decide which pages to create and which not to

Imagine research confirms that guided hiking and e-bike experiences are two distinct offerings, with sufficiently different demand and selection processes.

In that case, two service pages would make sense.

Each could explain its activity, show evidence and support booking.

But what do we do with family experiences?

We could create a specific page for every combination:

Family hiking.

Easy hiking for children.

Mountain excursions for families.

Family cycling routes.

Easy activities for children.

However, that could multiply pages with very similar content.

Instead of deciding based on keyword variations, we need to examine the actual offering.

If family experiences are not independent services, it may be more useful to incorporate specific information into the relevant pages.

For example, the hiking page could explain which routes suit particular ages, provided the business can confirm that information.

The e-bike page could explain its requirements and limitations for younger participants.

An informative piece could help families understand which factors to consider before choosing an activity.

Now consider private experiences.

If there is a distinct proposition with its own characteristics, conditions and demand, developing a specific page could make sense.

But if it is simply a booking option for the usual excursions, explaining it within each service may be sufficient.

The decision depends on the actual difference between the offerings and the needs of those searching for them, not just the words used.

Step 6. We build a provisional architecture

After these decisions, we might reach the following structure:

HOME

ACTIVITIES

• Guided hiking
• Guided e-bike routes
• Private experiences (if research justifies a separate offering)

ABOUT US

• Team and experience

RESOURCES

• How to choose a family mountain excursion
• Tips for taking a guided e-bike route

CONTACT

This representation shows a conceptual organisation. It does not mean every page must appear in the main menu or that grouped sections must be reproduced literally in URLs.

Nor is it a final recommendation for any real company.

It is the illustrative result of architecture decisions.

The next step would be to define their relationships.

Step 7. We connect the pages within a journey

Imagine a family arrives from Google at an article about choosing a mountain excursion suitable for children.

The article answers their questions about difficulty, duration, preparation and things to check.

Where appropriate, it can introduce the company’s guided experiences and link to its hiking page.

There the family will find the available activities, their characteristics, terms and a way to enquire or book.

We have not forced users to begin at the homepage.

Nor have we turned the informative article into an advertising page.

Each piece serves a purpose.

The resource informs.

The service page explains a specific proposition.

The booking system supports the purchase.

Links let the person move forward when they find a relevant option.

That is architecture serving the customer journey.

Step 8. We define the pages before designing them

Finally, every important page needs a functional definition.

For example:

This brief can already guide subsequent work.

The designer knows the page’s function.

The writer knows which information to explain.

The developer can understand which functionality it needs.

The person responsible for measurement knows which relevant actions to observe.

We have not created the page yet.

But we have already resolved a considerable portion of the decisions that determine its usefulness.

5. When to create a new page and when not to

One of the most important decisions in website architecture is determining which needs deserve a separate page.

There is no universal rule.

A query may be answered in a section, a service page, an informative guide or an existing resource.

It may also make no sense to develop content for it.

When a dedicated page adds value

Creating a separate page may be justified when there is a clearly differentiated offering, a specific need or an answer requiring sufficient depth.

For example, a company offering guided hiking and canyoning will probably need to explain those services separately.

The activities involve different characteristics, terms, risks and booking decisions.

Grouping them exclusively on a generic page could make both harder to understand.

But that conclusion must be tested against the actual offering and the way users search for information.

When a section is enough

At other times, a question can be adequately answered within an existing page.

Imagine customers want to know whether pets are allowed on excursions.

If the answer depends on the activity, including that information on the respective service pages may be more useful.

We do not automatically need a separate page titled “Excursions with dogs”.

It would only make sense if there were a differentiated proposition or an information need justifying a deeper answer.

When supporting content is appropriate

Some searches do not express an immediate intention to book.

But they can represent relevant questions within our customers’ journey.

A guide to preparing for a mountain excursion can help people still considering different activities.

That content can have its own informative purpose and relate to the corresponding services.

It does not need to become a disguised commercial page.

Its value lies in properly addressing a need.

Google recommends prioritising useful, reliable content for people rather than producing pages mainly to manipulate visibility in search results. [6]

When we should create nothing

We also need to recognise searches outside our proposition.

There may be demand for a service we do not offer, a query we cannot answer rigorously or content whose maintenance would be disproportionate.

In those situations, deciding against a page can be perfectly reasonable.

Well-designed architecture is also recognisable by the pages it has chosen not to build.

The problem with overly similar pages

This is where SEO cannibalisation appears.

In practical terms, we are concerned about several pages on our site attempting to answer the same need almost identically, overlapping without useful differentiation.

But we must avoid an overly simplified interpretation.

Two pages appearing for the same search does not automatically mean there is a problem.

An informative guide and a commercial page can share terms while addressing different needs.

They can also complement one another through internal links.

What matters is investigating whether there is harmful overlap.

If two pages provide almost the same answer, merging them may be appropriate.

If they address different needs, specialising them and clarifying their functions may be preferable.

If a page provides complementary information, it can remain as supporting content.

The aim is not to prevent different pages sharing keywords. It is to avoid unnecessary duplication and ensure each provides recognisable value.

6. How pages connect: hierarchy, navigation and internal links

Architecture does not end when we decide which pages a website will have.

We also need to define their relationships.

This organisation lets people find information, understand where they are and continue towards relevant content.

Hierarchy organises knowledge

Hierarchy establishes the main areas and which content belongs to each.

For example, a company may have a general activities area organising different experiences.

That relationship helps people understand how its offering is structured.

But related pages do not all have to depend visually or technically on the same folder chain.

Hierarchy is a conceptual decision.

Navigation makes access easier

The main menu should guide people towards the most important areas.

It need not show every existing page.

We can use secondary menus, contextual links, categories or specific components to enable other journeys.

The choice depends on the site’s complexity and its users’ needs.

A menu with few options does not automatically demonstrate good architecture.

Nor does one with many options necessarily mean poor design.

What matters is that people can find what they need without facing confusing organisation.

Internal links connect related needs

Internal linking connects pages that provide complementary information.

For example, a guide to family excursions can link to suitable activities.

A service page can link to booking terms.

A general section can present the different lines of offering.

These links help people continue their journey and allow search engines to discover pages and understand relationships within the site.

Google highlights the importance of making relevant content accessible through crawlable links. [2]

However, links should reflect real relationships.

We do not need to connect every page to every other simply to increase internal link counts.

Breadcrumbs help people find their way

Breadcrumbs are elements that show a navigation path or location within the site.

For example:

Home → Activities → Guided e-bike routes

They can be useful where there are different categories and levels.

They help people understand a page’s context and return to broader areas.

But they do not replace good structure or belong on every page by default.

Their usefulness depends on the site.

Checking whether people find what they need

Architecture should not be validated solely because a diagram seems logical to those who worked on it.

It should be tested with users.

We can ask someone to find an activity’s terms or identify where they would look for a family experience.

If they do not know where to look, section names, content classification or navigation may be problematic.

Techniques such as tree testing evaluate findability within a structure without visual design influencing the test.

Other tests can help identify difficulties with navigation elements.

Nielsen Norman Group describes different methods for distinguishing content organisation problems from interface problems. [7]

Not every website needs extensive research.

But even a simple check with people unfamiliar with the structure can reveal important difficulties before all pages are developed.

Architecture must make sense to the person using the website, not only the person building it.

7. A new website and an existing website start from different places

So far, we have used the example of a company that needs to reorganise its digital presence.

But there is an important difference between building a new website and renewing one published years ago.

In both cases we must understand the business, research demand and define coherent architecture.

What changes is the starting information.

When we build a new website

We begin mainly with knowledge of the business, its offering, customers and market research.

We do not yet have our own website whose results we can analyse.

Some decisions will therefore rely on informed hypotheses.

We need to investigate what people search for, how other companies respond and which structure can best address those needs.

We will then build the assets and begin observing their actual behaviour.

The initial architecture must be solid enough to guide development while allowing adjustments as new information emerges.

When we renew an existing website

An additional responsibility arises here.

The website may have accumulated value over years.

It may have pages receiving relevant visits, content linked from other sites or URLs generating business enquiries.

It may also contain useful information for customers who already know those addresses.

An outdated design does not mean we should remove the entire previous structure.

An existing website is not a blank page. It is a set of assets with a history we need to understand.

Example: renewing a website without destroying its value

Imagine a company has fifteen service, activity and destination pages.

The new design proposes simplifying navigation and reducing them to six.

Visually, this may seem an improvement.

But first we should investigate what happens to the nine pages that would disappear.

Some may be almost identical and worth merging.

Others may answer very specific searches and deserve to remain.

We may also discover pages that need updating but still serve an important purpose.

That is why renewal should include an inventory of existing assets.

We need to know their content, URLs, relevant links, behaviour and business contribution, as far as available data allows.

Then we can decide what to preserve, improve, merge or retire.

What happens when URLs change

Changing an address can have consequences.

A page may receive links from other websites or be saved in users’ bookmarks.

If it disappears without an appropriate alternative, those people may encounter an error.

We may also make it harder for search engines to recognise where content has moved.

That is why migrations need planning.

Where an equivalent new page exists, a permanent redirect from the old address may be appropriate.

Google recommends permanent server redirects, such as 301 or 308, for permanent URL moves, alongside preparing mappings and monitoring the migration. [8]

But we should not indiscriminately redirect all removed pages to the homepage.

We must assess each case and offer a relevant destination where one exists.

It can also be correct to retire content that no longer makes sense without forcing an artificial equivalence.

The aim is to protect people’s experience and preserve existing useful value as far as possible.

Modernisation should not begin with destruction

This principle connects directly with digital asset direction.

When a company decides to renew its website, we should not treat everything that came before as a problem that must disappear.

First we must recognise what works.

Then we decide what to improve.

New architecture may require deep changes, but should justify them through business, experience and SEO criteria.

Renewing a website does not necessarily mean starting from scratch. It means building a better version from the knowledge and assets we already have.

8. What should be ready before design and development

Once the architecture is defined, we need to turn it into a reference that design, content and development teams can use.

An attractive diagram is not enough.

We need to preserve the decisions that justify the structure.

In a professional project, this blueprint can consist of different working tools.

The page map

It shows which pages the site will contain, how they are grouped and their main relationships.

It need not exactly reproduce the menu or technical URL structure.

Its purpose is to represent the system’s organisation.

Demand research and the SEOMap

They document the needs identified, how these appear in searches and the pages assigned to address them.

They explain why a page was proposed and what purpose it should serve.

They also help prevent new content unnecessarily reproducing existing material.

Functional briefs

They define the responsibilities of each important page.

They may include its audience, main intent, required information, evidence, actions and relationships with other sections.

They guide the work without prematurely deciding every aspect of design.

Navigation and linking decisions

They establish how people will find their way and which relationships must be accessible.

They identify main content, groupings and relevant links.

The inventory and migration decisions

Where a previous website exists, we need to document which pages remain, which change, which content is merged and which URLs require technical action.

This means developers do not have to interpret on their own what should happen to existing assets.

Requirements for the build

Finally, we should identify conditions affecting design and development.

For example, booking functionality, information requirements, navigation behaviour, indexing needs or actions to observe through measurement tools.

Not every project requires the same depth for each element.

A simple website may need much more compact documentation than a platform with hundreds of pages.

What matters is making essential decisions explicit.

The blueprint’s value is not measured by the number of documents it produces. It is measured by the decisions it enables without improvisation.

Design, content and development need a shared reference

Design must turn the structure into an understandable visual experience.

Content must respond to the identified intentions and needs.

Development must implement the planned pages, relationships and functionality.

Technical SEO must check that search engines can access and correctly interpret content intended to be discovered.

Each discipline brings its own expertise.

Architecture does not seek to replace that professional judgement.

It does allow the work to begin from shared decisions.

Imagine that, during writing, we discover two planned pages explaining almost the same offering.

We may need to reconsider their differentiation.

Or a navigation test shows that people do not understand a category.

We can change it.

Architecture must be able to evolve when new evidence emerges.

The difference is that we now know which decision we are changing and its possible consequences for the whole.

The blueprint does not remove creativity. It gives it direction and lets us evaluate proposals with better judgement.

9. Architecture ready to evolve

The way people find and use digital information is changing.

Search engines incorporate new query experiences, and artificial intelligence tools increasingly participate in research, comparison and work tasks.

Some systems can consult information published on a website and use it to answer questions or help carry out certain actions.

This adds possibilities, but does not change a fundamental need.

Businesses still need to present their services properly, explain their terms and maintain consistent, current information.

Information must be understandable and verifiable

Think again of our mountain experiences company.

A person needs to know which activities it offers, where they take place, their conditions and how to book them.

Those same characteristics may also matter to digital systems able to access and interpret the information.

Coherent architecture helps organise it.

But it does not guarantee that a search engine, assistant or external agent will discover the website, use its content or recommend the company.

Those outcomes depend on multiple factors, including each platform’s access mechanisms and operation.

Where appropriate, we can complement good architecture with structured data, machine-readable information and technical access mechanisms.

But these tools do not replace content quality or truthfulness.

Nor do they automatically turn a website into a system capable of receiving bookings through agents.

These are different capabilities that must be assessed according to business needs.

Build for the business, not the fashionable tool

A company may change its content management system, renew its design or introduce new forms of interaction.

But its services, customers and fundamental needs should not have to be redefined from scratch whenever technology changes.

That is why architecture decisions should be separated from the tools used to implement them.

A coherent structure can guide website development using different technologies.

It can also support maintenance, evolution and new functionality.

This does not mean every technological change will be simple.

It means retaining the knowledge needed to understand what we have built and why.

Good architecture should not depend exclusively on the tool used to develop the website. It should represent business logic and people’s needs.

10. The blueprint before you build

A website can be visually appealing, technically fast and developed with modern tools.

But if its structure does not address business and customer needs, it will still have important limitations.

Better design, more traffic or more pages do not by themselves correct a structure that responds poorly to business needs.

Architecture lets us address these questions before committing a substantial part of the investment.

It helps us understand which pages the business really needs, which demand they should address and how they should relate.

It also protects existing assets and prevents unnecessary construction.

But its main value is not in producing a sitemap or list of URLs.

It is in turning strategic knowledge and demand research into decisions usable during design, writing and development.

A website should not begin by asking how many pages we want to build. It should begin by understanding what the business needs to resolve and how we can organise the answers its customers expect.

With that blueprint, design, content and development can advance from shared decisions that can be revised as new evidence emerges. It does not guarantee everything will work from day one; it reduces improvisation and enables learning without losing direction.