DEV Community: Morlix CMS

Morlix Blog Pro: Editorial Planning and Shared References

Евгений Брусницын — Thu, 29 Oct 2026 15:42:18 +0000

Editorial Planning That Survives Handoffs: Morlix Blog Pro and Shared References

A list of article ideas is useful, but it is not an editorial workflow. A reliable publishing process also needs context, source verification, visual direction, approval rules, and a way to confirm that a story has actually gone live.

Morlix Blog Pro connects these concerns through an editorial plan and a shared reference library. The plan defines the job; references keep the visual output consistent; delivery records distinguish publishing a page from distributing it elsewhere.

What belongs in an editorial topic?

In the current Morlix editorial records, a topic includes its title, category, priority, keywords, brief, visual brief, publication policy, and selected social networks with their respective modes. These are separate decisions.

A keyword identifies a search intent. A brief defines the useful answer. A visual brief describes the concepts the artwork should convey. Publication policy specifies whether the content can be released automatically or must wait for approval.

For example, an article about editorial planning should show how a topic progresses through writing, verification, and publication. Its illustrations should explain the workflow or the reference library—not depict an unrelated installation tutorial.

References are instructions, not decoration

A reference library works best when it distinguishes fixed brand assets from flexible design guidance.

The current Morlix reference set separates its official logo from a broader visual direction. The logo must remain faithful to its source file. The broader direction describes a light, premium technology look, cool blue and smoky-gray tones, and soft lighting. An illustrator can interpret that mood without inventing a new corporate mark.

Descriptions should explain what may change, what must remain consistent, and which visual mistakes to avoid. This helps both human designers and AI-assisted workflows.

Five stages of a dependable editorial process

1. Find the existing work

Search both published posts and drafts before creating a new article. Two different titles may address the same user question. If a topic already points to a draft, continue it instead of creating another URL.

2. Verify claims

Product content should describe features that are actually confirmed. A connected social integration does not prove that a message was delivered. Likewise, an image import request does not prove that the file is publicly accessible. Distinguish a feature's existence, its configuration, and a successful end-to-end result.

3. Write for the reader and for search intent

Lead with a clear answer. Organize details under meaningful headings, then add a concise page title, description, readable URL, and relevant internal links. Do not invent release dates or promise rankings and traffic.

4. Treat images as content

A cover introduces the article. In-article illustrations should explain different parts of the topic. Each needs a useful alt description.

Morlix provides a media-checking tool that reports S3 object existence, MIME type, and public HTTP status. That verifies file delivery, not visual authenticity. Concept art must never be presented as a genuine screenshot of the CMS.

5. Confirm publication and close the task

A saved draft is not a live page. After publication, verify the article status and its public URL, then mark the related editorial topic complete. Revision checks help prevent stale edits from overwriting a newer version.

When a remote operation returns an ambiguous error, read the current state before retrying. Blindly repeating a publication or social post can create duplicates.

Manual review and distribution

Some materials need a human decision. Under the current Morlix editorial policy, technical guides in the designated guides category require manual approval. An automated editor can prepare the draft but must not release it without the owner's review.

Social distribution is another distinct step. Telegram, VK, Bluesky, Mastodon, and other services have separate opt-in choices and delivery statuses. Short announcements can point back to the original article. A full English-language edition for DEV Community should be written for English-speaking readers, not copied from Russian without editorial adaptation.

The important metric is not how many publish buttons were pressed. It is whether the original article and each selected external message reached a confirmed final state.

Why it matters

Site owners gain visibility into progress. SEO specialists can align topics with intent and avoid redundant pages. Agencies can keep multiple writers aligned with one visual language. Automated editors gain a source of truth more dependable than a static prompt.

The outcome is a repeatable publishing process: each topic has a purpose, each illustration has a role, and each release has a verifiable status.

This is an independently edited English-language overview. Read the original Russian article on Morlix CMS.

Original article (Russian)

Visual Hierarchy in Web Design: A Practical Guide to Directing Attention

Евгений Брусницын — Thu, 29 Oct 2026 14:31:01 +0000

Visual Hierarchy in Web Design: How to Guide Attention

Visual hierarchy is the order in which visitors notice and understand the elements of a page. It determines whether someone recognizes the purpose of a website, finds the information they need, and identifies the next action. Good hierarchy is not about making everything bigger or brighter. It is about setting priorities through size, contrast, spacing, alignment, color and content.

This guide explains how to build a usable hierarchy in common pages, including homepages, service pages, catalogs and mobile layouts.

Start With the Visitor's Task

Before opening a design tool, write down what a visitor needs to accomplish. On a service page, they may need to understand the offer and contact the team. On a product listing, they need to compare products. In an article, they should be able to find an answer and scan related sections.

Define a single primary purpose for each screen. Secondary links and decorative elements can support that purpose, but they should not compete with it. A useful exercise is to hide all the colors and illustrations: can someone still tell what the page is about and where to go next?

Size and Type Establish a Reading Order

A large headline often attracts attention first, but size works only when the difference between levels is clear. When every section has a huge headline, nothing looks more important.

Use a limited type scale: a main headline, section headings, body copy and supporting labels. Keep line lengths comfortable and spacing consistent. On smaller screens, a headline that occupies four or five lines may push the useful content below the fold, so test actual narrow widths rather than simply reducing every font by the same percentage.

Use meaningful HTML heading levels. The H1 describes the main page topic; H2 and H3 establish nested sections. Choose appearance with CSS rather than skipping semantic heading levels to get a smaller visual size.

Contrast Should Explain Priorities

Contrast is not just a bright accent color. A dense shape surrounded by whitespace, a dark heading on a light page or a large element next to smaller elements all influence what visitors notice.

For a primary call to action, choose a recognizable treatment that stays consistent across the website. If four actions look equally prominent, visitors must work harder to decide what matters. Reserve strong emphasis for genuinely important steps.

Readable text contrast is also an accessibility requirement. Check actual color combinations against the relevant WCAG guidance instead of relying only on how attractive they look in a mockup.

Spacing Shows Which Elements Belong Together

People tend to group objects that appear close to one another. A heading, description and button for one service should feel like a unit. Separate units need larger gaps.

Build a spacing scale, then apply it consistently. Random margins can destroy a good visual hierarchy even when colors and typography are polished. A simple test is to draw a rectangle around each logical group: if the boundaries are unclear, adjust the internal and external spacing.

Alignment Makes Pages Easier to Scan

Consistent alignment gives the eye predictable anchor points. Repeated cards should place names, prices and actions in consistent positions. For paragraphs in left-to-right languages, left alignment is generally easier to scan than centering long text.

A centered hero can work for a short headline, but extensive descriptions benefit from a stable reading edge. There is no universal F- or Z-shaped path that visitors always follow. Their attention depends on content, the device and their intent.

Use Color as a System, Not Decoration

Define roles for colors: canvas, primary text, muted text, accents, success, warnings and errors. Make the same interaction look recognizable on different screens.

Do not make color the only indicator of state. Add a label, shape or clearly named icon when an element conveys an error, success or warning. Include hover, focus and disabled states in the design system.

Build a Useful First Screen

Consider a website for a development studio. The opening screen should explain the service in a concrete headline, say who it is for, and offer a clear next step such as “Discuss a project.” A secondary link might point to selected work.

A polished 3D illustration can reinforce the message, but it should not overlap the headline or appear more important than the actual offer. If the visitor cannot understand the service without watching an animation, the hierarchy probably needs revision.

Product Cards and Catalogs

Product listings are particularly sensitive to competing details. A typical card may contain a picture, title, price, rating, badge, shipping information and action. Decide which fields visitors need for the first comparison and give those fields predictable placement.

Do not make ratings, discounts, labels and buttons equally prominent. The goal is a repeatable comparison pattern, not a collection of attention-grabbing decorations. Important purchase conditions must remain discoverable even when they do not receive the strongest visual emphasis.

Accessibility and Mobile Layouts

Visual hierarchy must survive zoom, long strings, dynamic text sizing and keyboard navigation. Check focus visibility, appropriate HTML heading semantics and a reading order that matches the logical content sequence.

On mobile, do more than stack desktop columns vertically. Reconsider what appears first: is the value proposition visible before a long decorative illustration? Does a sticky panel cover the main action? Can users scroll without accidental gesture-driven changes? Test narrow screens, rotated devices and enlarged text.

A Practical 15-Minute Audit

Try this on an existing website:

Squint at the page for several seconds. Which two or three areas stand out? Do they reflect the visitor's task?
View the page in grayscale. Is the relative importance still clear without the accent colors?
Read only the headings. Can you understand the page's structure?
Find the primary call to action. Do competing buttons or decorative shapes distract from it?
Repeat the exercise at a narrow mobile width, including with larger system text.
Note specific problems and make one adjustment at a time.

Common issues include too many equally strong accents, muted text that is too faint, gaps that split related information, impressive but confusing hero sections, and animations that compete with essential content.

Evaluate Outcomes, Not Just Appearance

A visual change is successful when people can carry out their tasks more easily. Ask visitors to find a price, locate an important condition or send an inquiry. Observe where they hesitate and what they overlook.

Click maps and scroll analytics can help identify suspicious areas, but they do not explain why users behave a certain way. For major changes, controlled comparisons can be useful when there is enough reliable data. Never claim a conversion lift solely because a design looks more modern.

Keep Hierarchy Stable in a CMS

Even a good design system can deteriorate when content changes. Editors should have guidance on headline length, image ratios, card structure and the number of competing primary actions. Component rules help new pages remain coherent without requiring a designer to revisit every update.

For technical accessibility criteria, consult the WCAG 2.2 Quick Reference.

Takeaway

Effective hierarchy starts with the visitor's task. Make one main message obvious, use consistent typography, spacing and color roles, then validate the layout on mobile and with real people. Motion and decoration are useful only when they reinforce clarity.

This article is an independently written English adaptation of the original Morlix CMS guide: Visual Hierarchy in Web Design.

Original article (Russian)

How to Build a Website with AI: A Practical Workflow and Its Limits

Евгений Брусницын — Thu, 29 Oct 2026 14:03:12 +0000

Building a website with AI is possible in several ways: an AI-powered visual builder, an assistant integrated into a content management workflow, or AI-assisted code generation. The right choice depends on what the site must do after its first attractive preview.

This guide walks through a practical workflow, explains where AI helps, and identifies the checks that still require human judgment.

What AI can actually do

AI can help draft a sitemap, propose page sections, rewrite verified business information, create a first visual direction, explain code, and suggest test cases. Depending on the tool, it may also generate HTML, CSS, JavaScript, or a complete prototype. None of those outputs is proof that a site is ready for customers. The owner remains responsible for accuracy, accessibility, security, privacy, and maintenance.

A landing page with a simple contact form is a very different project from a store that handles orders and payments. AI may accelerate both, but the second requires a much deeper engineering and operational review.

Three practical routes

1. AI website builder. Describe the business and let a visual builder generate a starting layout. This is convenient when you want to edit blocks without writing code. Check domain support, export options, accessibility, and the real cost of ongoing use.

2. AI assistant alongside a CMS. Use AI for drafts, information architecture, alt-text suggestions, and editorial workflows while a content management system controls publishing and user permissions. This is useful when multiple people will maintain the site.

3. AI-assisted coding. Ask a model to generate components or explain implementation choices, then keep the code in version control and test it like any other software. This offers flexibility but requires someone who can identify broken dependencies, security issues, and incorrect assumptions.

Start with a brief, not a prompt trick

Write down the site's purpose, intended audience, primary conversion, geography, and essential pages. Gather authentic service descriptions, prices or pricing rules, contact details, photographs, and legal information. Identify which data users will submit and how the organization will process it.

A useful brief for a furniture repair workshop might say: “Our customers are homeowners in one city. The main goal is to request an estimate. We need pages for services, examples of completed work, frequently asked questions, and contact details. Do not invent prices, testimonials, certifications, or delivery terms. Identify information that the business owner must supply.”

This approach turns the model into a planning assistant rather than an unreliable source of business facts.

A step-by-step workflow

Step 1: Define the user journey

Choose one primary action: request a quote, book a call, buy a product, or read a guide. Sketch the shortest path from the landing page to that action. A site with many decorative sections but no clear next step is not finished.

Step 2: Draft the information architecture

Ask AI for a sitemap and the purpose of each page. Remove redundant pages. For a small service business, a homepage, service pages, examples, FAQ, and contact information may be sufficient. Add policy pages appropriate to the data collected and the applicable rules.

Step 3: Prepare content from verified inputs

Use the model to organize real facts, not fabricate them. Confirm all prices, service areas, response times, credentials, and claims with the business. Replace generic marketing phrases with specifics a customer can check.

Step 4: Build a prototype

Choose a visual builder, CMS, or code-based workflow. Generate the first layout, then adjust typography, spacing, hierarchy, and navigation. Treat any AI-generated screen as a concept until it has been implemented and tested in a browser.

Step 5: Review before launch

Test navigation, forms, responsive layouts, keyboard access, image loading, and error states. Verify metadata and internal links. If the site takes payments or handles sensitive data, arrange appropriate specialist review before accepting real transactions.

Where AI-generated sites fail

Models can hallucinate company details, produce inaccessible controls, suggest nonexistent APIs, or create code that works only in the demonstration. They can generate visually impressive pages with weak mobile layouts, confusing calls to action, or forms that silently fail.

Another common problem is repetitive SEO copy: every page uses similar headings and generic paragraphs without answering a distinct question. Generating more pages is not the same as creating more value. Review each page against the actual search intent and the user's next decision.

Never paste passwords, private API tokens, production customer databases, or other secrets into a public model prompt. Generated code should undergo dependency checks, input validation, permission reviews, and testing on a nonproduction environment.

Accessibility and performance

Check contrast, text scaling, keyboard navigation, visible focus indicators, form labels, meaningful alt text, and responsive behavior. Do not rely on color alone to communicate errors or status. The W3C Web Content Accessibility Guidelines provide a useful framework, but a generated design is not automatically compliant.

Measure the experience on a normal phone and an ordinary network, not only on a powerful development machine. Compress images appropriately, avoid unnecessary effects, and ensure the most important content remains usable while assets load. Performance and accessibility need practical testing, not just AI approval.

SEO: make each page useful

Start with the questions a visitor actually asks. Give each page a clear purpose, descriptive title, useful body content, sensible headings, and relevant internal links. Check the canonical URL, indexing settings, and any redirects. Do not create dozens of near-duplicate location or keyword pages just because generation is inexpensive.

Google's guidance on helpful, reliable content is a better foundation than promises of instant rankings. AI assistance does not remove the need for expertise, fact-checking, and a good user experience. Neither an AI-generated description nor a score from a plugin guarantees search performance.

Choosing the right platform

For a one-off campaign, a builder with a visual editor may be enough. For a frequently updated publication, prioritize content management, roles, media handling, backups, and portability. For a complex service with accounts, integrations, or payments, plan for professional development and maintenance.

Before committing, ask: Can we export our content? Who owns the domain and project files? Can editors change the site without regenerating it? How are backups restored? What happens when a subscription ends? Which SEO and accessibility controls are actually available? Review current documentation and terms, because product capabilities and prices change.

A realistic acceptance checklist

All business claims, contact details, and terms have been verified.
Every link, navigation item, button, and form has been tested.
The site works on desktop and narrow mobile screens.
Forms show understandable success and error messages.
Keyboard users can reach important controls.
Images have appropriate descriptions and usage rights.
Titles, descriptions, URLs, and indexing settings are reviewed.
No secrets are exposed in client-side code or prompts.
Backups, updates, and ownership responsibilities are defined.
A test inquiry or transaction reaches the intended recipient.

The checklist is deliberately operational. A beautiful preview is not a substitute for a working site.

A small business example

Imagine a repair workshop with real photos, a defined service area, and a goal of receiving estimate requests. AI proposes a sitemap and a draft FAQ. The owner corrects the answers, supplies authentic images, and approves the service descriptions. A builder or developer creates the site, and another person tests whether they can find a service and send a request without guidance.

If prices depend on the item's condition, the page should explain the estimation process instead of inventing a fixed price. This small decision illustrates the broader principle: use AI to clarify and accelerate real work, not to replace facts with confident guesses.

What to measure after publishing

Track whether visitors can complete the primary action, whether messages are delivered, and where they encounter friction. Review real questions from customers and update the content. A site that took two hours to generate but needs weeks of correction is not necessarily more efficient than a carefully scoped implementation.

Measure the total effort: planning, revisions, testing, ongoing costs, and support. Use AI for tasks where it saves time without undermining reliability. Keep a human owner for content, product decisions, and production changes.

Bottom line

AI can make website creation faster, especially during research, planning, prototyping, and drafting. It cannot independently guarantee truthful business information, safe code, accessible interfaces, or a sustainable publishing workflow. Start with a concrete goal, use the right tool for the project, verify every consequential claim, and test the result with real users before launch.

Original article (Russian)

What Does a CMS Actually Do? A Practical Guide to Content Management

Евгений Брусницын — Thu, 29 Oct 2026 13:16:12 +0000

What Does a CMS Actually Do? A Practical Guide to Content Management

A content management system (CMS) is the part of a website that lets a team create, organize, update, and publish information without editing the site's source code for every change. That definition is useful, but incomplete. A CMS is also a data model, a set of permissions, a publishing workflow, and a bridge between stored information and the pages visitors see.

If you are choosing technology for a company website, blog, documentation portal, or small online store, understanding those responsibilities is more valuable than comparing long feature checklists.

Content and Presentation Are Different Jobs

Imagine a service company with thirty service pages, a team directory, news, and case studies. The content team needs to change descriptions and upload images. The development team needs to keep navigation, layout, forms, and responsive behavior consistent.

A CMS separates these jobs to a useful degree. Editors work with structured fields such as title, summary, body, image, category, and publication status. Templates determine how those fields appear on the public website.

This separation is not absolute. Visual editors may let authors assemble entire pages, while highly structured systems deliberately restrict layout choices to protect consistency. Neither approach is automatically better: the right degree of flexibility depends on the team.

The Request-to-Page Journey

A typical publishing flow has four steps:

An editor enters information. A person with appropriate permissions creates a draft, chooses a content type, and fills in its fields.
The CMS validates and stores it. Text and metadata are often stored in a database. Images and other assets may be stored separately, with references saved alongside the content.
The website retrieves the content. When a visitor requests a URL, the application finds the relevant record, checks its visibility, and selects a suitable template or API response.
The visitor receives a page. The browser renders HTML, CSS, images, and JavaScript. Caching or static generation may change when the page is assembled, but not the need for a reliable content source.

This is a conceptual model, not a diagram of every CMS. A traditional server-rendered system, a static site generator, and a headless CMS can implement these responsibilities differently.

A crucial distinction: a saved draft is not necessarily public. Publication status and permissions must be enforced in the actual delivery layer, not just represented by a badge in the editor.

Five Parts Worth Evaluating

1. Content modeling

A blog post, product, event, and service page are not interchangeable. A product might need a price, SKU, stock status, and technical attributes. An event needs a location and start time. A strong content model stores these as separate fields where useful.

Structured content is easier to validate, filter, translate, reuse, and deliver to multiple interfaces. A single giant rich-text field can be convenient at first but difficult to maintain later.

2. Editorial workflow

Can an editor save a draft without publishing it? Can someone else review the content? Are revisions available? Is there an audit trail? These questions become important as soon as more than one person contributes.

Do not assume every product includes approval flows or rollback. Test the exact version and licensing tier you plan to use.

3. Templates and design

A template maps content fields into consistent pages. It controls the heading hierarchy, cards, navigation, and responsive layout.

The CMS does not automatically make a website accessible or fast. Those outcomes depend on template implementation, asset optimization, scripts, hosting, and testing.

4. Roles and security

An author should not necessarily be able to install plugins, change payment settings, or manage every user. Role-based access limits accidental damage and reduces the impact of compromised credentials.

Look for individual accounts, least-privilege permissions, secure authentication, and a clear process for revoking access.

5. Media and extensions

A media library may store images, alt text, filenames, and other metadata. Plugins or modules can add forms, catalogs, integrations, and search features.

Every additional extension introduces maintenance work. Track ownership, update frequency, compatibility, and backup requirements rather than installing components simply because they exist.

Traditional, Headless, and Static: Three Delivery Models

A traditional CMS typically combines the editorial backend and website rendering in one application. This can simplify preview and deployment for content-heavy sites.

A headless CMS focuses on managing and exposing content through APIs. A separate website or app renders the result. This is attractive when several frontends share one content source, but the team must handle frontend deployment, caching, preview, SEO, and integration work.

A statically generated site with managed content produces pages ahead of requests. It can reduce per-request server work, but content changes may require rebuilding and redeploying. Forms, search, authentication, and frequently changing data still need solutions.

These are architecture patterns, not mutually exclusive product labels. Some platforms support more than one model.

CMS vs Website Builder vs Custom Code

A website builder generally packages design tools, hosting, and simplified setup into one service. It can be efficient for a small brochure site or a short-lived campaign. Investigate export options and integration limits before committing.

A CMS often provides more flexibility for recurring content operations, multiple authors, and extensible structures. That flexibility comes with operational responsibility: updates, backups, security, and compatibility.

A custom application offers maximum control over unusual business logic, but the team must build or integrate editorial tools, roles, media storage, revision history, and publishing workflows.

The real question is not which category is most powerful. It is which approach meets your requirements with acceptable long-term maintenance.

What a CMS Can—and Cannot—Do for SEO

Useful capabilities include editable page titles and descriptions, readable URLs, appropriate heading structures, redirects, sitemaps, and indexing controls. Internal links and consistent category structures can help visitors and crawlers discover related content.

But a settings screen is not proof of correct output. Inspect rendered HTML, canonical URLs, response status codes, and the pages actually accessible to crawlers. An installed SEO plugin does not guarantee indexing or rankings.

Google's SEO Starter Guide is a useful primary reference for search fundamentals. Search engines can generate their own snippets even when a meta description is provided.

For performance, examine image sizes, script cost, caching, and hosting as well as the CMS itself. A slow page may be caused by a heavy theme or third-party widget rather than the content storage layer.

A Realistic CMS Evaluation Exercise

Instead of browsing screenshots, run a short pilot with the people who will use the system.

Start with content. Define three representative content types. For example: a service page with pricing details, a blog article with images, and a case study with related projects.

Test editorial work. Ask a nontechnical colleague to create, preview, revise, and publish a sample page. Record where they get stuck.

Test development work. Implement a template change and verify that existing content still renders correctly on mobile. Check that a long heading and a wide table do not break the layout.

Test operational work. Make a backup, verify the restore procedure in a safe environment, review the update process, and document who owns each step.

Test migration. Export a sample of content and media. Determine which metadata survives and what would need to be rebuilt on another platform.

Test security. Create an editor account and verify that it cannot perform administrator-only operations. Review authentication and access revocation.

This exercise is usually more revealing than a long list of features marked “yes.”

Common Mistakes

Choosing by theme appearance alone. A polished demo says little about content modeling, permissions, and maintainability.

Installing every available plugin. Extensions can increase attack surface, maintenance burden, and the chance of compatibility problems.

Using shared administrator credentials. Individual accounts and appropriate roles make accountability and access management possible.

Ignoring URL stability. Renaming published URLs without redirects can break links and create unnecessary crawl errors.

Treating backups as a checkbox. A backup is only useful if the team knows how to restore it and has tested that procedure.

Assuming a CMS is a marketing strategy. Software helps publish and manage content; it does not replace audience research, good writing, usability, or measurement.

A Short Selection Checklist

Before committing, answer these questions:

Can editors complete their daily tasks without developer assistance?
Does the content model reflect the information your business actually manages?
Are roles, previews, drafts, and revisions sufficient for your workflow?
Can the team inspect and control SEO-relevant output?
Is the site usable and accessible on mobile?
Are backup, recovery, updates, and extension ownership documented?
Can content and media be exported if the platform changes?
Does the total cost include hosting, development, and maintenance?

A modular product such as Morlix CMS is one possible option to evaluate, but confirm the specific capabilities of the deployed version against your requirements. A product's category does not prove it supports every workflow described here.

Final Takeaway

A CMS is an operating system for a website's content workflow: it helps people create information, store it consistently, control who can change it, and deliver it through a designed interface. The best choice is the one your editors can use safely and your technical team can maintain confidently.

Start with five everyday tasks, perform them in a test environment, and compare the friction and operational risks. That is a better basis for a decision than a feature count.

This English article is an independent editorial adaptation for developers and content teams. The original Russian guide is published by Morlix CMS.

Original article (Russian)

Building a Website from Scratch: A Practical Project Plan

Евгений Брусницын — Thu, 29 Oct 2026 09:59:01 +0000

Building a Website from Scratch: A Practical Project Plan

A website is easier to launch when you treat it as a product project rather than a design exercise. Before choosing a theme or buying a domain, decide who the site serves, what visitors need to do, and who will maintain it after launch. Those answers shape the page structure, technology, content, budget, and support work.

1. Define the outcome

Write a one-sentence goal: generate qualified enquiries, sell a product range, explain a service, showcase work, or publish useful resources. “Tell people about the company” is too vague to guide a sitemap or measure results.

Identify the audience and the questions they ask before acting. What do they need to compare? Which risks or objections need an honest answer? Choose one or two meaningful conversions, such as a completed enquiry form, booking, purchase, or subscription.

2. Choose the right format

A landing page works for one offer, campaign, or event. A company or services website needs a clear overview plus pages for distinct services, case studies, company details, and contact options. A catalogue or online store also needs product data, delivery and payment terms, returns information, and a reliable order workflow. A blog or resource site needs a sustainable publishing process, useful categories, author information, and archive navigation.

Do not create dozens of near-identical pages just to target keyword variations. Each page should answer a distinct user need.

3. Sketch the sitemap and user journey

Start with the essentials: home, services or catalogue, company information, contact details, and answers to common questions. Add a portfolio or blog only when it helps visitors decide.

For every page, record its purpose, key message, supporting material, and next action. Then test the journey: can a first-time visitor understand the offer, compare options, and contact you in a few steps? Important pages should not be buried deep in navigation. Use labels that visitors understand without knowing your internal terminology.

4. Choose a build approach

A hosted builder can be efficient for a small project, but check export options, plan limits, and integration constraints. A content management system (CMS) suits sites that publish regularly or need reusable page structures. Evaluate editing tools, media handling, user roles, SEO controls, backup and restore procedures, and update practices.

Custom development may be justified for unusual workflows or deep integrations, but budget for documentation, testing, security maintenance, and future changes.

If you are coding the site yourself, start with a small working version. HTML defines structure, CSS controls presentation, and JavaScript adds interaction. MDN’s Your first website guide explains how to plan, build, and publish a first page.

5. Register a domain and choose hosting

Choose a domain that is easy to say, type, and distinguish from competing names. Check availability and possible trademark conflicts. Confirm who controls the registration, who can access the registrar account, how renewals work, and how control can be transferred. ICANN’s domain registration overview explains the roles of registrars, registries, and registrants.

Choose hosting against the platform’s real requirements: supported runtime and database versions, storage, logs, TLS, backups, support quality, and a documented recovery path. Keep domain ownership and recovery details secure. Never put administrator passwords in a public project document.

6. Prepare content before finalising design

Draft real titles, service descriptions, prices, photographs, FAQs, and calls to action early. Actual content determines section order and page length.

Each page should answer a clear question. Replace vague claims with specifics: what is included, who the service is for, how the process works, what limitations apply, and what happens next. Never invent testimonials, certifications, customer counts, or results.

Use images that explain something. Compress them to appropriate dimensions, and write alternative text for informative images. Keep important copy as real text so it can be searched, resized, translated, and read by assistive technology.

7. Make mobile UX and accessibility part of the build

Check narrow screens from the start. Navigation should behave predictably, text should remain readable, and buttons and form fields should be comfortable to use. Use sufficient contrast, visible focus states, clear labels, and helpful error messages. Test keyboard navigation; do not rely on colour alone to communicate status.

Review more than the home page. Test a typical service page, article, form, product page, and error page. Replace demo content in themes and confirm that longer headings and paragraphs do not break the layout.

8. Establish a basic SEO and security baseline

SEO starts with useful information architecture and technical accessibility, not repeated keywords. Give important pages descriptive titles, clear headings, readable URLs, and helpful internal links. Check that key pages can be crawled, are not accidentally blocked from indexing, and return appropriate HTTP status codes. A sitemap and webmaster tools help you observe discovery and search performance; they do not guarantee indexing or rankings.

Before launch, remove test accounts, change default credentials, enable multi-factor authentication where available, and give each team member only the permissions they need. Make regular backups and test restoration. Apply CMS and extension updates, and remove components that are no longer used.

If the site collects personal information, identify the rules that apply to your business and audience. Explain why each form field is needed and avoid exposing sensitive values in logs or notifications.

9. Run a launch checklist

Verify that:

HTTPS works and the intended hostname is used.
Navigation, links, buttons, and forms work on desktop and mobile.
Test enquiries reach the right destination and show confirmation.
No placeholder copy, empty sections, broken images, or dead links remain.
Titles, descriptions, headings, canonical URLs, and indexing directives are correct.
Redirects and error pages behave as expected.
A backup exists and the responsible person knows how to restore it.
Contact details, prices, and legal information are current.
Analytics records the chosen conversions without unnecessary personal data.

Open the public site in a private browser window and ask someone unfamiliar with the project to complete a real task. Their hesitation can reveal confusing labels and missing information.

10. Launch, observe, improve

After testing, point the domain to production, remove temporary access restrictions, and verify the public version. Recheck after DNS changes because caching and configuration affect what visitors see.

During the first weeks, monitor uptime, server errors, form delivery, and user behaviour. Fix broken journeys before adding more features. Avoid changing the entire design, navigation, and copy at once if you want to learn which change helped.

The core principle is simple: build a tool that helps a real person complete a real task. Clear structure, accurate information, accessible pages, and a maintainable setup provide a stronger foundation than visual polish alone.

This is an independently written English edition. For the original Russian article, see Morlix CMS: How to Create a Website from Scratch.

Original article (Russian)

SEO for a New Website: A Practical Six-Month Roadmap

Евгений Брусницын — Wed, 28 Oct 2026 14:19:40 +0000

SEO for a New Website: A Practical Six-Month Roadmap

Launching a website is not the same as making its pages discoverable in search. A sensible SEO program starts with crawlability, a clear information architecture, useful content, and measurement. Backlinks and publishing volume cannot compensate for pages that search engines cannot reach or visitors cannot use.

This roadmap is for developers, small product teams, and site owners starting from limited organic visibility. Six months is a planning horizon, not a promise of rankings.

Month 1: Make the Website Technically Discoverable

Check URLs and indexing signals

Inspect your main templates and URLs: home, product or service pages, categories, and articles. Make sure they return appropriate HTTP statuses. Content pages normally return 200. Missing content should return a genuine 404 or 410 rather than a “not found” message served with 200.

Check the redirects between HTTP and HTTPS and your preferred hostname. Look for redirect chains, competing canonical URLs, and accidental duplicate routes.

Review robots.txt carefully. It controls crawling, not access security. If a page needs to be excluded from indexing using noindex, the crawler generally needs access to read that directive. Put private data behind authorization rather than depending on robots directives.

Create an XML sitemap containing canonical, useful, indexable URLs. A sitemap helps discovery; it does not guarantee indexing. Refer to Google's sitemap documentation.

Establish a measurement baseline

Verify ownership in Google Search Console and your relevant local search-engine webmaster tooling. Submit the sitemap. Configure analytics and meaningful conversions, while meeting applicable privacy requirements.

Keep a baseline of search impressions, clicks, indexed URLs, key pages, and conversion events. New properties may have little data, so avoid overreacting to short-term fluctuations.

Month 2: Research Intent and Build the Site Structure

A keyword list is not an information architecture. Start by clustering questions and searches according to their underlying intent.

For example, “what is a CMS?” needs an educational resource. “Buy a CMS license” needs a product page with clear terms. Combining these into one generic page often leaves both audiences underserved.

Collect ideas from customer questions, sales conversations, search suggestions, and search performance tools. Evaluate query patterns by market, device, and language instead of assuming one third-party volume estimate equals your future traffic.

Assign each intent cluster to the most appropriate page. For a software product, you might need documentation, feature pages, pricing, comparisons, integrations, and technical tutorials. Avoid creating numerous near-duplicate URLs just to match small keyword variations.

Use stable, readable URLs. If you change established paths, plan redirects and update internal links.

Month 3: Publish Content That Solves Real Problems

Prioritize pages that help actual decisions: the primary service or product pages, critical documentation, and a small number of substantial educational guides.

A useful page answers its core question quickly, explains trade-offs, gives concrete examples, and makes the next step clear. Claims about product features should be verified against the deployed version. A tutorial should distinguish tested steps from conceptual examples.

Use a descriptive title, one logical H1 in the final rendered page, and H2/H3 headings that reflect the article's structure. Meta descriptions can help explain a page, but search engines may generate snippets from other page content.

Write alternative text to communicate what an image conveys, not to repeat keywords. Add internal links when they genuinely help a reader move to related material.

You can inspect Morlix CMS for one example of a modular CMS project, but a CMS choice alone does not produce SEO results.

Month 4: Improve Page Experience and Performance

Test mobile navigation, forms, image handling, font loading, and JavaScript. Use both controlled lab tests and field data when available.

Core Web Vitals cover loading (LCP), responsiveness (INP), and visual stability (CLS). They are useful diagnostic signals, not a substitute for relevant content.

Compress images, consider modern formats such as WebP, and deliver responsive dimensions. Lazy-load offscreen media where appropriate, but measure the impact of lazy loading on a prominent hero image before adopting it.

Review focus states, keyboard accessibility, contrast, error messages, and the number of fields required to complete a task. Better usability helps visitors reach the outcome they came for.

Month 5: Build Useful Connections

Audit your internal linking. Important pages should not be isolated from navigation or relevant explanatory articles. Create natural paths between broad guides and narrower answers.

Fix broken links and remove unnecessary redirect hops. Do not stuff every paragraph with exact-match anchors.

Earn external references by publishing genuinely useful resources: original data, demonstrations, tools, tutorials, or case studies. Mass link packages and fictional testimonials create risk rather than durable value.

For local businesses, maintain accurate contact details, location data, and business profiles. International projects may require well-designed language variants and careful regional targeting.

Month 6: Evaluate and Reprioritize

Compare performance by page group and user intent, not only the site's overall traffic.

Pages with impressions but few clicks may need a better match between query intent, search-result presentation, and the content offered. Pages with clicks but no conversions need a review of their offer, trust signals, speed, and usability.

Avoid making major conclusions from a tiny sample. Account for seasonality, new launches, redirects, and changes to tracking.

A simple cycle works well:

Fix critical crawl, indexing, and UX defects.
Improve pages already attracting relevant impressions.
Fill genuine gaps in the content map.
Measure conversions alongside traffic.
Repeat with documented changes.

A Six-Month Checklist

Period	Focus	Evidence to review
Month 1	Technical access and analytics	HTTP codes, sitemap, indexing, events
Month 2	Query intent and architecture	Topic clusters, page map, duplicate URLs
Month 3	High-value content	Accuracy, examples, headings, links
Month 4	Usability and performance	Mobile journeys, LCP, INP, CLS
Month 5	Internal links and authority	Orphan pages, broken links, relevant mentions
Month 6	Analysis and next iteration	Impressions, clicks, conversions, priorities

Common Mistakes to Avoid

Buying links before fixing the website. External references cannot make an inaccessible page usable.

Publishing dozens of thin pages. More URLs do not automatically mean more topical authority.

Treating position tracking as the only KPI. Search visibility matters, but it must connect to useful user and business outcomes.

Changing everything every week. Without stable measurements, it is hard to understand which interventions help.

Believing the six-month timeline guarantees ranking. SEO is an iterative process, subject to competition, crawl behavior, and product quality.

Start with Ten URLs

Select ten important pages. Check their status codes, indexing directives, canonical URLs, user intent, and conversion paths. Confirm measurement, build the first topic map, and assign a realistic owner to each correction. This produces an actionable baseline without pretending that a fixed calendar can guarantee search results.

For further technical guidance, use the primary resources in Google Search Central and the documentation of the search engines relevant to your market.

This is an independently adapted English guide for developers. The original Russian article provides additional context for Russian-speaking site owners.

Original article (Russian)