Many websites are planned from the outside in.
The process begins with the pages people want to see in the navigation, moves to the homepage design and visual style, and only then attempts to fit the business's services, products, projects, and content into that structure.
For a small website with limited content and a simple business structure, this approach can hold up.
The problem begins when the website grows.
When the fiftieth project needs to be added.
When the product catalog gains a new category.
When another area of activity is launched.
When the marketing team needs to publish content regularly.
When another language is added.
And when the same information needs to appear in several contexts across the website.
At that point, it becomes clear whether the website was designed as a system or as a collection of pages.
Professional website architecture is not limited to deciding which pages a website will contain. It asks a deeper question:
What is the internal structure of the business, and how can it become a consistent, manageable, and scalable digital model?
What is website architecture, really?
The term "website architecture" is often used as a synonym for a sitemap, navigation menu, or URL structure.
Those are only its outward expressions.
In a professional process, website architecture is created where four layers meet:
The business model — what the business offers, how its activity is organized, how it sells, and which kinds of information it manages.
Information architecture — how users discover content, understand relationships, and move between parts of the website.
The content model — which entities exist in the system, which fields define each entity, and which relationships connect them.
The application architecture — how the model becomes routes, dynamic templates, components, a content management system, data sources, and rendering rules.
Architecture therefore does not begin with the question, "How many pages do we need?"
It begins with questions such as:
What are the central entities in the business?
What is the difference between a category, a service, a product, and a project?
Can a project relate to more than one service?
Should an article support a particular service journey?
Which information repeats?
What should be managed once and displayed in several places?
Which parts of the structure are fixed, and which need to remain dynamic?
And what happens when the amount of content doubles?
The pages are the outcome of those decisions, not their starting point.
Dlatot HaMoshav: turning a project gallery into a dynamic catalog model
Dlatot HaMoshav presents a broad range of work and products: entrance doors, interior doors, staircases, wall cladding, and custom projects.
At first glance, the website could have been planned as one large gallery.
One page, hundreds of images, and a basic visual division.
But a gallery is a display format. It does not necessarily represent the information structure of the business.
When someone looks for an entrance door in a particular style, they are not searching for "another beautiful image." They are searching within a defined field, category, and type of work. From the business's perspective, each project is not isolated either; it belongs to a broader product world.
The architecture was therefore built around a hierarchical model:
Domain → Category → Subcategory → Model or project.
At the implementation level, that hierarchy is also expressed in the route structure:
/gallery/[category]/[subcategory]/[slug]
This is not an incidental technical detail.
The path reflects the item's place in the business model: which domain it belongs to, which subcategory contains it, and which specific item the user is viewing.
Instead of developing a separate page manually for every gallery and project, I built a system of dynamic templates. Each model or project is entered as a structured content unit, and the system generates the appropriate page, assigns it to the right categories, and positions it within the navigation flow.
Architecturally, there is an important separation between three things:
- The information — the project name, description, category, subcategory, and media.
- The display rules — how a certain type of project is presented.
- The position in the system — the galleries, pages, and contexts in which it appears.
That separation makes it possible to add a new project without redefining the website structure each time.
The system does not merely "know" how to display an image. It knows what the image represents, which item it belongs to, in which context it should be shown, and which pages relate to it.
The business impact
For the user, the result is the ability to move from the general to the specific:
From a broad domain to a relevant category, a specific style, and finally a project or model.
For the business, the result is a catalog that can expand without creating operational chaos.
For the content team, it means that every new project enters an existing, consistent structure instead of becoming another standalone page that requires fresh design and development decisions.
From an SEO perspective, the value does not come from having many URLs. It comes from creating a consistent hierarchy, logical internal links, clear semantic context, and distinct content at every layer.
Architecture does not guarantee rankings. It creates the conditions that allow search engines to discover, understand, and map website content more effectively.
PROJECT SYSTEM / 01: not a catalog, but decision architecture
PROJECT SYSTEM / 01 is a neutral demo of a website system for a service business that grows through projects and case studies. Its business model is fundamentally different from a product catalog.
There is no product catalog that users need to filter by type, material, or style.
There is a studio offering different engagement processes, projects that demonstrate professional ability, content that answers common questions, and a journey in which a prospective client needs to understand which path suits them.
It would therefore be wrong to take the architecture built for Dlatot HaMoshav and simply replace its colors and imagery.
The same technology can serve both architectures, but the business model must dictate a different structure.
At Uni.Mi, the website design and development product is built on Uni.Mi Foundation, which supplies the shared engineering mechanisms. Uni.Mi CMS is the operating product that turns that website's content model into ongoing management, publishing, measurement, and improvement.
In the project system, the central entities are:
Services, engagement tracks, projects, articles, and conversion actions.
The important relationship is not only hierarchical. It is also the relationship between a need, a service, and proof.
The main user journey looks like this:
Need → Service track → Professional explanation → Relevant project → Proof → Fit call.
A service page is therefore not merely a page of text explaining what the studio offers.
It is a node in the system.
It should connect to projects that demonstrate the service, articles that answer questions raised before purchase, and the next action the user should take.
Likewise, a project is not simply an image gallery.
From a content perspective, a project is a proof object.
It documents a type of process, scope of work, professional context, outcome, and service type. When it is connected correctly to the model, it does more than present the business's visual language; it helps a client understand what the business can deliver and through which professional process the result was created.
Articles play another role within the website.
They are not a detached content layer intended only to "bring traffic." They are part of the decision architecture. Each article can address an objection, explain the difference between service paths, support a particular service, and lead the user to the next relevant piece of content.
The result is a relationship system:
Service ← Project
Service ← Article
Project → Relevant Service
Article → Relevant Service
Service → Conversion
This is not only navigation architecture.
It is architecture that connects information, proof, and business action.
STORE / 01: when a catalog becomes a purchase journey
STORE / 01 demonstrates a different system. It is not a website that sells a service through proof, but a digital store that must connect discovery, choice, and purchase.
A beautiful product grid is not a store by itself. For the catalog to operate as a commerce system, each product needs to be a structured entity with a name, description, price, media, collection membership, purchase options, and relationships to other products or sets.
The store system is built around these entities:
Products, collections, sets, favorites, bag, and order.
Its central journey looks like this:
Need → Discovery → Product → Compare or save → Set → Bag → Order.
Every product passes through the same dynamic template. Adding a product unit does not require another React page; data and media feed the template, which handles the route, information hierarchy, imagery, purchase actions, and commercial relationships.
In the current Edition, favorites, bag, and checkout demonstrate the purchase journey using local demo data only. There is no live payment processing and no connection to customer data. The demo is not selling a specific integration. It shows that the architecture already understands the relationships a commerce system must manage.
The result is another relationship system:
Collection ← Product
Product ↔ Related Product
Product → Favorite
Product → Bag
Set → Products
Bag → Order
The system's value is not the number of store screens. It is the ability to add products, change relationships, and extend the commercial journey without rebuilding the shopping experience each time.
The same label, three different architectures
The Dlatot HaMoshav catalog, PROJECT / 01, and STORE / 01 all represent dynamic websites that expand through new structured content units.
Architecturally, however, they solve different problems.
At Dlatot HaMoshav, the system's backbone is a catalog taxonomy: domains, categories, subcategories, and items.
In the project system, the backbone is a relationship system and decision process: need, service, project, professional knowledge, and conversion.
In the store system, the backbone is a commercial journey: discovery, product, comparison or saving, set, bag, and order.
At Dlatot HaMoshav, the user narrows the possibilities until reaching a relevant item.
In the project system, the user builds understanding and confidence until they can select a service and make an inquiry.
In the store system, the user moves from discovering a product to choosing and purchasing within one coherent commercial context.
That distinction matters because it shows that website architecture is not a generic solution.
You cannot choose the "right website structure" before understanding:
How the business sells,
how its customers make decisions,
which content it creates,
which relationships exist between content types,
and how the business is expected to change over time.
That is also why a ready system cannot be a generic visual shell. Even when the process begins with an architecture that has already been designed and tested, its content model, relationships, and conversion path still need to be adapted to the business.
The business domain remains the starting point, and the system is configured from there.
How do you translate a business into digital architecture?
The process does not begin with a wireframe and does not end with a sitemap.
1. Map the business domain
The first step is learning the system the website needs to represent.
What does the company sell?
How are its services, products, and projects organized?
Which processes exist behind the scenes?
What should the marketing team be able to manage?
And which growth scenarios are likely?
The goal is not to collect a list of pages. It is to identify the logical structure of the operation.
2. Define entities and relationships
Next, the central units of information are defined.
For example:
Product
Category
Subcategory
Project
Service
Article
Media
Location
Team Member
Each entity receives fields, attributes, and relationships.
A project can relate to a service.
An item can belong to a category and subcategory.
An article can support several engagement tracks.
An image can belong to a project while also appearing on a category page.
This stage forms the foundation of the content model and management system.
3. Build the taxonomy and URL structure
Not every business division needs to appear in the navigation, and not every field in the system should become a page.
This is where decisions are made about:
- Which content deserves an independent landing page.
- Which category should be directly navigable.
- Which attribute is used only for filtering.
- How the business hierarchy relates to the URL structure.
- How consistency is preserved as the website grows.
The URL structure should be an outcome of the model, not an accidental collection of page names accumulated over the years.
4. Design the dynamic templates
Only after the entities and relationships are clear can the website's templates be defined.
Instead of thinking about one hundred project pages, we define one project template that accepts structured information and presents it consistently.
Instead of developing every category manually, we define generation and display rules for categories.
That is the difference between building pages and developing a system.
5. Design user journeys and internal links
Good architecture does not stop once all content exists.
It defines how users move between pieces of content.
What is the next logical content item?
Which project should appear beside which service?
Where should an article lead?
Which action fits the user's current stage?
And what happens when someone enters through an internal page rather than the homepage?
The homepage is only one entry point into the system.
Every meaningful page should provide context, continuity, and a next action.
6. Plan management, measurement, and growth
A dynamic website must be operable, not merely displayable.
Architecture therefore also affects:
The management system — which fields editors enter, which relationships they choose, and which outputs are generated automatically.
Content governance — how consistency, naming, assignments, and structures remain intact when several people manage the website.
Measurement — whether interest can be measured by category, service, project, or journey rather than only by page views.
Performance — which data each template loads, how media is managed, and what can be rendered in advance.
Expansion — whether adding a language, region, category, or content type requires a focused change or a rebuild.
These decisions are not made after the design is complete.
They are part of the architecture on which the design depends.
Why does this matter especially for companies planning to grow?
A company does not need a website only to present what it has today.
It needs a system that can support its operation tomorrow.
When the architecture is designed correctly:
New content enters an existing structure.
Pages are generated from consistent templates.
Relationships between services, projects, and articles do not depend on manual work each time.
Content and marketing teams can operate more independently.
Measurement aligns with the business model.
And the website does not lose clarity as the volume of information grows.
When architecture is not planned, every change becomes a local patch.
A page is added.
A template is duplicated.
A new URL is invented.
A category is created that does not fit the existing model.
And content is connected manually in more and more places.
Over time, the result is architectural debt: a website that is difficult to understand, manage, measure, and expand.
In an era when screens are easy to generate, good systems are harder to build
Automation tools, templates, and AI systems can generate impressive pages quickly.
They can suggest visual hierarchy, colors, copy, and components.
But they do not release a company from the architectural questions:
What business model does the website represent?
What are its central entities?
Which relationships need to exist between them?
What is managed as content, and what is embedded in code?
How is consistency preserved?
And what happens when the system becomes ten times larger?
The easier it becomes to generate the interface layer, the more important the thinking beneath it becomes.
A professional website is not measured only by how it looks on launch day.
It is measured by its ability to remain clear, stable, and useful after the business, content, and team have changed.
At Uni.Mi, I design and develop dynamic websites from the structure and logic of the business.
I do not begin with a page count.
I do not force the company into a generic shell.
And I do not treat content as something that fills the design after the system has already been built.
I begin with the business domain, define the content model and its relationships, and only then translate them into navigation, templates, routes, a management system, and the user experience.
Design is the interface layer of a website.
Architecture is its operating mechanism.
—
Uni.Mi — Make your digital unique.