Many websites are planned from the outside in. The process starts with a page list, moves to the homepage design, and then tries to fit the business into that structure.
That can work for a small, static website. It starts to fail when the catalog grows, another language is added, the team publishes regularly, or the same information needs to appear in several places.
At that point, the difference is clear: the website is either a system or a collection of pages.
Website architecture should express how the business works, not just how its navigation looks.
What website architecture actually covers
Professional website architecture is not limited to deciding which pages a website will contain. A sitemap, navigation menu, and URL structure are only its visible parts.
A durable architecture connects four layers:
The business model: what the company offers, how it sells, and how its work is organized.
Information architecture: how visitors find content, understand relationships, and choose a next step.
The content model: which entities exist, which fields define them, and how they relate.
The application architecture: how the model becomes routes, templates, components, data sources, publishing rules, and a content management system.
The first question is not, "How many pages do we need?" It is, "Which business entities and relationships must the website represent?"
A project may support more than one service. An article may answer a question within a specific buying journey. A product may belong to a category, a collection, and a set. Information that appears in several places should be managed once.
Pages are the output of those decisions.
Dlatot HaMoshav: from gallery to catalog
Dlatot HaMoshav presents entrance doors, interior doors, staircases, wall cladding, and custom projects. A single gallery could display the work, but it would not reflect how customers search or how the business organizes its catalog.
A visitor looking for an entrance door in a specific style is not looking for another attractive image. They are narrowing a defined product field. Each project also belongs to a wider category and product world.
The architecture therefore follows a hierarchy:
Domain → Category → Subcategory → Model or project
The route reflects the same model:
/gallery/[category]/[subcategory]/[slug]
Each segment tells the system where the item belongs. An editor can add a structured project once, and the website can place it in the correct route, gallery, and related context.
The model separates three responsibilities:
- Information: project name, description, category, subcategory, and media.
- Display rules: how this type of project appears.
- System position: the routes, galleries, and contexts in which it belongs.
That separation allows the catalog to grow without creating a new page structure for every item.
What the architecture changes
Visitors can move from a broad domain to a category, style, and specific model. The business can expand the catalog inside a consistent structure. The content team can publish without making fresh design and development choices for every project.
The SEO value is not the number of URLs. It comes from a coherent hierarchy, distinct content, useful internal links, and clear semantic context. Architecture does not guarantee rankings, but it helps search engines discover and understand the catalog.
PROJECT / 01: architecture for a service decision
PROJECT SYSTEM / 01 is a neutral demo for a service business that grows through projects and case studies. It has no product catalog to filter by material or style. It needs to connect a visitor's need with a service, professional context, proof, and an inquiry.
Reusing the Dlatot HaMoshav structure with different colors would miss that business model.
At Uni.Mi, the website design and development product is built on Uni.Mi Foundation, the shared engineering layer. Uni.Mi CMS turns the website's content model into ongoing management, publishing, measurement, and improvement.
The central entities in the project demo are:
Services, engagement tracks, projects, articles, and conversion actions
Its main journey is:
Need → Service track → Explanation → Relevant project → Proof → Inquiry
A service page is a node in this system. It connects to projects that demonstrate the service, articles that answer buying questions, and the next useful action.
A project is a proof object, not just an image gallery. It can document the context, process, scope, outcome, and related service without claiming results the demo does not provide.
An article has a different job. It can explain a decision, answer an objection, support a service, and move the reader to the next relevant page.
Service ← Project
Service ← Article
Project → Relevant Service
Article → Relevant Service
Service → Conversion
This architecture connects information, proof, and action.
STORE / 01: architecture for purchase
STORE / 01 demonstrates another system. It connects discovery, selection, and purchase instead of selling a service through proof.
A product grid is only a visual layer. A commerce model needs each product to be a structured entity with a name, description, price, media, collection membership, purchase options, and related products or sets.
The central entities are:
Products, collections, sets, favorites, bag, and order
The journey is:
Need → Discovery → Product → Compare or save → Set → Bag → Order
Every product uses the same dynamic template. Product data and media feed the route, information hierarchy, imagery, and commercial relationships.
In the current Edition, favorites, bag, and checkout use local demo data. There is no live payment processing and no customer-data connection. The demo shows the relationships a commerce system must manage; it does not claim a live integration.
Collection ← Product
Product ↔ Related Product
Product → Favorite
Product → Bag
Set → Products
Bag → Order
The value is not the number of screens. It is the ability to add products and extend the purchase journey without rebuilding the store.
One label, three architectures
Dlatot HaMoshav, PROJECT / 01, and STORE / 01 are all dynamic websites. They solve different business problems.
- Dlatot HaMoshav uses catalog taxonomy: domains, categories, subcategories, and items.
- PROJECT / 01 uses decision architecture: need, service, knowledge, proof, and inquiry.
- STORE / 01 uses a commercial journey: discovery, product, comparison, bag, and order.
One narrows a catalog. One builds confidence in a service. One moves toward a purchase.
That is why a tested foundation cannot be a generic visual shell. Its content model, relationships, and conversion path still need to fit the business.
How a business becomes website architecture
The work starts before wireframes.
1. Map the business domain
Define what the company sells, how services or products are organized, what the team must manage, and how the offer may grow. The output is an operating model, not a page list.
2. Define entities and relationships
Identify the central information units:
Product
Category
Subcategory
Project
Service
Article
Media
Location
Team Member
Then define their fields and connections. A project can support a service. An item can belong to a category and subcategory. An article can support several service paths. Media can appear in more than one relevant context.
This becomes the content model and the base of the management system.
3. Shape the taxonomy and routes
Decide which content deserves its own page, which category belongs in navigation, which attributes should remain filters, and how URLs express the hierarchy.
Routes should follow the model instead of becoming a list of page names accumulated over time.
4. Build dynamic templates
Once the model is clear, define reusable templates. One project template can render structured project records consistently. One category template can apply the same rules to every category.
This is the practical difference between building pages and building a system.
5. Connect the user journey
Every useful page needs context and a next action. A service should lead to relevant proof. An article should answer a real question and point to the right service. A project should explain what it proves.
The homepage is only one entry point. Internal pages must work as complete steps in the journey.
6. Plan management and growth
The architecture also defines:
- Management: what editors enter and what the system generates.
- Governance: how naming and relationships stay consistent.
- Measurement: how interest is tied to services, categories, and journeys.
- Performance: which data and media each template loads.
- Expansion: how a new language, region, or content type is added.
These are design inputs, not tasks to postpone until launch.
Why growing companies need the model early
With a clear architecture, new content enters an existing structure, templates stay consistent, and measurement follows the business model.
Without it, every change becomes a patch: another duplicated template, an improvised URL, or a category that does not fit. That creates architectural debt and makes the website harder to manage, measure, and expand.
Screens are easier to generate. Systems are not
Templates and AI tools can produce polished screens quickly. They cannot decide which business entities matter, how they relate, what belongs in content rather than code, or how the model should behave when it grows.
The easier the interface becomes to generate, the more valuable the structure beneath it becomes.
At Uni.Mi, website design and development starts with the business domain. I define the content model and relationships, then translate them into navigation, templates, routes, management, and user journeys.
Design is the interface layer. Architecture is the operating model.