CONTENT SYSTEM DESIGN
Content as a system.
From meaning to structure
We define what materials your site needs, what task each page solves, and how they are connected. We provide a map, content models, and an implementation plan that editors, designers, and developers can work with.
AUDIENCE
TASKS
CONTENT
COMMUNICATION
MODELS
PROTOCOLS
from registry to implementation
CLARITY
INTEGRITY
DEVELOPMENT
projects
of studio
models
Premier Partner status
marketing, analytics
We design content, connections, and rules
Content architecture is needed when launching a site, reworking a catalog, developing a blog, or unifying disparate materials. It connects business objectives, audience questions, and site structure: from what a person needs to understand to where information is stored and how it is updated.
We start with an inventory of pages, products, and available expertise. For each material, we define the audience, task, sources, and next step. We use search queries along with customer questions and product logic: they help find topics, but do not replace design.
We develop page types and material models: required fields, blocks, relations, metadata, and approval roles. We record what to save, update, merge, or create. Then we assemble an implementation queue with dependencies and acceptance criteria.
- Registry of existing content and material solutions
- Sitemap based on audience tasks and products
- Models for services, articles, cases, and reference materials
- Navigation and content linking rules
- Editorial policy and implementation priorities
Registry
What exists and what requires change
Map
Page tasks and transitions
Models
Fields, blocks and data sources
Regulations
Who creates, checks, and updates
Result — working documentation
The editor receives tasks and quality rules, the designer receives the composition and hierarchy of blocks, the developer receives the model of fields and relations. We agree on the volume of documentation for the project; we accompany solutions with an explanation of the task and the verification method.
Architecture on three levels
So that materials work together and the site can be developed without accumulating duplicates and contradictions.
Tasks and information routes
We define what the visitor needs to know at different stages of decision-making. We separate service materials, comparisons, instructions, and case studies. For each, we define the input, main question, evidence, and the next relevant step.
Content models and relationships
We describe a repeatable structure: fields, blocks, entities, and relationships between them. For example, a case is linked to a service, industry, and verified result, while an instruction is linked to a topic, expert, and verification date. This is the foundation for consistent templates and CMS.
Editorial management
We define factual sources, roles, approval, and maintenance. We identify who is responsible for the data, how drafts with AI are checked, and when the material needs to be reviewed. We pass on rules that the team can apply after the project is completed.
From inventory to implementation queues
Every stage ends with a decision or document that can be verified and approved.
Context and inventory
We collect business tasks, products, audiences, and a list of materials. We identify duplicates, outdated information, weak pages, and content gaps.
Audience tasks
We analyze customer questions, search topics, and available analytics. We form task groups and map them to products and decision-making stages.
Content map
We define sections, page types, URLs, and the role of each material. For an existing site, we prepare solutions for preserving, updating, and merging pages.
Models and relationships
We describe mandatory fields and blocks for standard materials, navigation, and relevant links. We verify the structure using service, article, and case study examples.
Editorial rules
We agree on fact-gathering, author tasks, expert roles, AI usage, proofreading, and updates. We prepare starting tasks in the volume of the package.
Implementation plan and acceptance
We set priorities and dependencies, assign roles. We hand over documents and verification criteria; we plan development and content production as separate tasks.
What will get your team
Six parts of documentation. We fix the volume and detail of each in the task for the selected package.
Registry and solutions
Materials table: URL, type, status, responsible person and action. To merge pages, we record the reason and required verification before changes.
Sitemap
Hierarchy of sections and a table: audience, task, page type, URL, input, and next step. New pages have a justification in the product and audience needs.
Material models
Specifications of selected page types: mandatory and optional fields, block structure, data sources, and relationships. We verify models with examples.
Relationship matrix
Navigation and internal linking rules with examples. We specify which pages should be accessible from sections and which links really help the visitor.
Editorial policy
Author, editor, and expert roles; procedure for gathering facts, proofreading, approval, and updating. We separately define AI usage and fact-checking.
Implementation plan
Task queue with priority, dependencies, and readiness criteria. We mark where texts, design, CMS setup, development, or analytics verification are needed.
Example of a related material systems
For a company with a technical product, three materials answer different questions and complement each other.
Service: what you offer
Task: help evaluate a suitable work format. Fields: scope, conditions, limitations, price or estimation method, confirmations, and contact. Connections: relevant cases and preparation instructions.
Case study: how you solved the task
Task: show experience on a verifiable example. Fields: context, source data, solution, result, and source of measurement. Connections: service and other projects in the same industry.
Instruction: how to prepare
Task: help a person perform a specific action. Fields: conditions of use, steps, examples, author or expert, sources, and date of verification. Connections: materials for the next step and service if help is needed.
— COST
Pricing
to architecture
One-time design. The price depends on the number of material types, sections, and the depth of development.
| Scope of work | Basic architecture Small service site or one section 25 000 ₽ Up to 7 days | POPULAR Comprehensive strategy Website and blog with multiple content types 55 000 ₽ Up to 14 days | Enterprise Architecture Catalog or large content project from 95 000 ₽ From 20 days |
|---|---|---|---|
|
Search topics
|
Up to 300 requests | Up to 1,500 requests | From 5,000; volume according to task |
|
Sitemap and URLs
|
Main pages and sections | Full site and blog hierarchy | Categories, filters, and material types |
|
Content models
|
Main page type | Key material types | Entity models and their relationships |
|
Navigation and links
|
Basic transition rules | Thematic relationship matrix | Rules for dynamic and cross-links |
|
Development plan
|
For 3 months | For 6 months | For 12 months |
|
Initial tasks for authors
|
Up to 5 technical specifications | Up to 20 technical specifications within the project | Quantity and formats as per task |
|
Verification and transmission
|
Map verification and document transmission | Relationship verification during acceptance | Control policy and launch plan |
Timelines are calculated after receiving materials and access. The composition of page types, number of sections, and model depth are fixed in the task. Writing all texts, design, CMS development, page migration, and regular maintenance are priced separately; documents include a plan for these works.
— QUESTIONS AND ANSWERS
Everything that matters
before start
Scope of work, source materials, approval order, and launch conditions.
-
How is this different from a content plan and SEO audit?
A content plan determines what and when to publish. SEO audit identifies existing site issues. Architecture defines the composition and role of materials, page models, relationships, and management rules. It uses audit results and includes a development plan, but its primary output is a content system design. -
What we will receive and who to pass the result to?
Sitemap, solutions for existing materials, content models, relationship rules and editorial work, as well as an implementation queue. The specific depth is agreed upon depending on the package. The documents are intended for the editor, designer, developer, and product owner. -
Is it possible to work with an existing website?
Yes. We start with a page registry and available analytics. First, we determine what to keep and improve. Before merging or changing URLs, we check links and search data; we prepare a migration plan. Mass deletions and redirects are not performed automatically. -
Does it include copywriting and website development?
The project includes structure and documentation, as well as starting assignments for authors within the plan's volume. Content production, template design, and CMS configuration are separate tasks. We show their scope and dependencies in the plan so you can evaluate the implementation. -
How does architecture help SEO?
Clear sections, useful materials and informative links help visitors and search engines navigate the site. During design, we consider search tasks and avoid unreasonable duplication. Positions depend on many factors; the site map itself does not guarantee reaching the top. -
How do I know the project is accepted?
We check that agreed pages have a task, a place in the structure, and a next step, models are tested on examples, and rules can be applied to new material. The implementation plan specifies priorities and readiness criteria. Metrics after launch are agreed upon separately: for example, finding necessary information, transitions, and calls.