How to build
a website that converts

What makes a website convert, and how do you measure the result?

A website that converts helps people understand the offer and take the next step: place an order, request a quote, book an appointment or discuss a project. A prominent button alone is not enough. Visitors need to reach the right page, find answers to their questions, see reasons to trust the company and submit an enquiry without errors.

Start with one sentence: “The website lets [which customers] [complete an action], after which [what the company does].” For example: “A buyer chooses suitable equipment and submits a specification, then an engineer prepares a proposal.” This is more useful than “build a modern website”: it immediately implies a catalogue, specifications, file upload and an enquiry workflow.

Measure more than button clicks

Choose the main outcome and agree what counts as a qualified enquiry. In B2B, it might come from a company that matches your target profile, with a suitable need and budget. In ecommerce, it could be a paid order, accounting for cancellations and returns. Viewing a page, opening a form and submitting it are separate events; they must not be added together as one “sale”.

For every metric, specify the period, source and denominator. Do not compare user-based conversion with visit-based conversion. Calculate customer acquisition cost separately from cost per enquiry, and state clearly which expenses are included. There is no universal “good conversion rate” for every market: channel, price, demand, sales cycle and measurement rules all affect it.

Understand the customer's task before planning pages

Talk to the sales team and review real enquiries: what customers ask first, which terms they clarify, why they decline and whom they compare you with. For a new business, start by interviewing potential buyers. Record their actual wording, not just the audience's age and job titles.

How to use Yandex Wordstat

1. Open Wordstat and enter the name of the service or product in the customer's own words.
2. Look at phrases related to the main query: price, quote, installation, maintenance, a particular model or region.
3. Compare regions and demand trends. Do not treat a seasonal spike as a permanent level of interest.
4. Group queries by intent: choosing a supplier, comparing options, checking specifications or solving a problem. Map each group to a future page.

Wordstat reports query statistics, not a guaranteed number of buyers. Word forms, operators, region and period affect interpretation; do not turn summed query frequencies into a revenue forecast. Supplement search data with customer conversations and sales information.

How to learn from competitors

Choose several websites from search results for your commercial queries. For each, record the intended audience, the promise, the supporting evidence, the terms disclosed and where the button leads. Test the journey on a phone. Separately note unanswered questions. Do not copy whole structures or wording: they may reflect another business model or simply repeat someone else's mistakes.

Stage deliverable: a concise table of segments, tasks, concerns, evidence and actions. Use it to explain why each section of the future website is needed.

Make an offer you can substantiate

The first screen should explain what you do, for whom and what next step you offer. Specifics matter more than grand claims. “Comprehensive innovative solutions for your success” could describe almost any company and does not help people choose a provider.

These are teaching examples, not promises from a particular contractor. Include a deadline, guarantee or fixed price only if the company can honour it and explains its limits. A fake countdown or unverified figure may attract attention but creates misleading expectations.

Match the ad's promise to the page

If an ad offers a quote for a warehouse, visitors should immediately see an offer for a warehouse. A generic homepage about company history makes them search again. Create separate pages for tasks with substantially different terms, arguments and buying journeys. But do not create dozens of near-identical pages just to swap a keyword.

Choose a format for the user journey, not the latest trend

Both a landing page and a large corporate website can convert. The difference lies in the number of tasks, offers and data involved. One long page is not automatically more effective than a catalogue; a multi-page website is not automatically harder to use if its navigation meets the customer's needs.

A practical structure for a service page

1. The offer. What you solve, for whom and what action is available now.
2. Use cases. Help people recognise their situation and understand the limits.
3. What's included. What the customer receives: work, materials, documents and access.
4. Evidence. Relevant examples, verified results with context and qualifications.
5. The process. What information is needed, who is involved and how decisions are made.
6. Price and terms. What affects the cost, what's included and what costs extra.
7. Address concerns. Timelines, compatibility, handover and ongoing support.
8. The next step. A form or contact option that explains what happens next.

The order depends on the situation. For a standard product, price and availability may matter before the brand story. For a complex project, first explain the working method and limits of responsibility. Do not add a section merely because the template includes it: it should help people make a decision.

Create a site map: home → service lines → specific services → related cases and resources → enquiry. For each URL, identify the main audience and action. This helps avoid pages competing to serve exactly the same need.

Test the content and user journey first

A wireframe is a plan for the future page with real headings, the purpose of each section and available actions. It reveals gaps before expensive visual work begins. A grey rectangle labelled “case study” does not answer the trust question: at this stage, you already need to know which project you can show and what you are allowed to say about it.

How to test a wireframe

1. Choose a task: “Find the service for your property and submit a technical brief.”
2. Give the participant a starting page and the task, without explaining where the buttons are.
3. Observe where they look for terms, what they skip and what they ask before submitting.
4. Record unclear wording, missing information and unnecessary steps.
5. Fix the problem areas and repeat the same task. Test the mobile version too.

A few observations like these can reveal major obstacles, but they cannot provide a statistical sales forecast. If a participant completes the task only after a hint, record that rather than counting it as an unassisted success.

What to give the designer: page structure, completed content blocks, examples of real materials, form states and a device list. For planning and design this is a more precise starting point than a collection of favourite websites without explanation.

Make the page clear and convincing

Each screen needs a visual hierarchy: the main point first, then explanation and action. Do not give every button equal prominence or turn every line into a large heading. Visitors should quickly distinguish the main next step from a link to extra information.

Which materials help people decide?

• Photos and demonstrations. Show the product, property, team or interface being discussed. Images from another industry undermine the page's message.
• A case study with context. Explain the starting challenge, work delivered, measurement conditions and a result you can substantiate.
• A breakdown of the offer. Help people compare options and understand what's included in the price.
• Process and ownership. Show what is needed from the client and who will lead the work.
• Terms and limitations. Resolve uncertainty that a quality slogan cannot address.

If you do not yet have relevant case studies, show your working method, a sample document or a clearly labelled demonstration prototype. Do not present a teaching mockup as delivered client work, or a calculated model as measured client growth. Publish testimonials and logos only when you have a valid basis for using them.

Mobile needs its own journey test

On a narrow screen, check more than heading wraps: test the menu, tables, form, file uploads and the on-screen keyboard. Main text and important images must remain accessible. A complex table may have its own scroll area; it must not stretch the entire page.

Navigate the interface with Tab: focus should be visible and the sequence logical. Label fields and describe errors in words. These principles are covered in detail in the W3C guide to accessible forms. Good design lets people complete the task when they use a different device or input method too.

Choose a platform based on how the website needs to work

List the required operations before choosing a site builder, CMS or custom development. Consider who will edit content, how the catalogue works, what data goes to CRM, whether an account area is needed and what you plan to add in a year. The same platform may suit a simple campaign but be awkward for a complex workflow.

Write a brief that can be tested

Instead of “we need CRM integration”, describe a scenario: a successful form submission creates an enquiry with the name, contact details, task, page URL and campaign tags; an owner is assigned; repeat submissions follow an agreed rule. Add the expected behaviour when CRM is unavailable. This description can be estimated, built and tested.

For each feature, record the inputs, action, outcome and exceptions. List pages and templates separately: ten pages using one template and ten different interfaces involve different amounts of work. Include content entry, migration of old URLs, integrations, testing, editor training and post-launch support.

What the estimate should include

The estimate links cost to stage deliverables: research and structure, wireframe, content, design, development, integrations, testing and launch. Each stage needs a scope, handover format and completion criterion. List subscriptions, licences, hosting, ad spend and future development separately to distinguish one-off development from recurring costs.

If the budget is limited, make the first release a complete core journey. For example, start with key services and reliable enquiry handover, then add a complex calculator after validating demand. Keep the less visible but essential parts: saving enquiries and analytics matter from the first launch. We explain project scope in our website development section and our guide to development costs.

Design the next step down to the details

A button should explain the action: “Submit a technical brief”, “Request a quote” or “Book an appointment”. Nearby, explain what the person will receive and which details are required. If a quote needs a discussion with an engineer first, do not promise an instant price.

Which form fields to keep

Collect the information needed to deliver the promised action or handle the enquiry. Contact details and a brief task may suffice for an initial conversation. Equipment pricing may need site parameters or a file. Shorter forms are not an end in themselves: an overly short form can increase unsuitable enquiries and the sales team's workload.

Distinguish required fields from optional ones. Do not ask users to re-enter details already selected on the page. Explain accepted file formats and show clear errors. Display success only after processing has been confirmed, not immediately on a click.

How to test the entire chain

1. Notify the responsible person about the test and fill every field with recognisable test data.
2. Submit the enquiry and record the time and page.
3. Find the CRM record and the notification in the intended channel.
4. Check the contact, comment, selected product, file, source and assigned person.
5. Repeat with an invalid required field and check that no false success appears.

When an external service fails, you need to know whether the enquiry was saved and how staff will learn about the failure. Designing this behaviour is part of CRM implementation and integrations. Agree the data-processing policy, grounds for collection and necessary documents for the actual process: a generic line beneath a button cannot cover every situation.

Prepare the website to attract visitors

Plan the structure of search-facing pages before launch. Each service needs relevant content and a clear URL; navigation must connect important pages. An article answers an informational question, while a commercial page explains the offer. Link them where the service helps solve the problem discussed.

Basic search readiness

• Meaningful title tags, main headings and descriptions for every important page.
• Access without an accidental password restriction or noindex directive.
• Correct canonicals, an XML sitemap and robots.txt rules.
• Working internal links and redirects from important old URLs.
• Substantive text and images relevant to the topic.
• Connected search-engine tools with access granted to the client.

To check the basics, use the Google SEO Starter Guide. Search readiness does not guarantee a ranking: the site still needs useful content that earns attention and meets real demand. Connect your promotion plan with product development and SEO work, not just filling in plugin fields.

Check speed without losing content

Open PageSpeed Insights, test the homepage and different page types on mobile and desktop, and save the reports. Identify images, fonts or scripts delaying content; check image dimensions and whether space is reserved for them.

The first screen should load promptly; images far down the page need not compete with it for network capacity. After optimisation, check that illustrations, menus, forms and analytics still work. A detailed sequence with tools and explanations is available in our guide “How to accept a website from a developer”.

Measure the journey to a qualified enquiry and a sale

Create an event map before launch. For each goal, specify the action, when it is recorded and where it is confirmed. Opening a form signals interest, successful submission creates an enquiry, and CRM qualification establishes whether it fits the business. The last event cannot be reliably inferred from a browser click alone.

Check goals in Yandex Metrica

Sign in to Metrica and make sure your website's tag is selected. With the new tag code, open the page using the parameter ?_ym_debug=2, perform the action and inspect Events and Console in the debug panel. If the URL already has parameters, use &_ym_debug=2. Compare the event with the report, allowing for filters and processing delays. The older-code method and troubleshooting are explained in Yandex Help.

Click the button while required fields are empty. The “Successful enquiry” goal must not fire. Then submit correctly and refresh the page: check that the goal is not recorded again without a new enquiry.

How to choose the next improvement

Review the funnel by channel and device. No relevant visits? Check acquisition. People read but do not act? Examine the offer, terms and trust. They start the form but leave? Check fields, errors and mobile usability. Many enquiries, few qualified? Review the promise, audience and qualification. Qualified enquiries but no sales? Also examine sales handling and the offer's terms.

Do not change the offer, ad audience and form simultaneously if you want to understand what caused the result. An A/B test needs sound visitor allocation, a preselected metric and enough data. A handful of enquiries does not prove a variant won. With little traffic, first fix observed obstacles and run qualitative journey checks.

Plan the launch and first improvements

Before publication, run acceptance checks against the agreed criteria. Repeat critical actions after moving to the live domain: test settings and real integrations may differ. Assign someone to review enquiries and someone to fix technical errors.

1. Before launch: check content, every form, access permissions, main devices, search settings, backups and analytics.
2. Immediately after launch: visit the live URLs; check HTTPS, redirects, delivery of a test enquiry and event collection.
3. Once data is available: compare channels, landing pages, devices and enquiry quality. Do not judge conversion from an overly small sample.
4. For the next release: choose a problem with a clear impact, define the hypothesis and test criterion, then release and measure the change.

Give the editor instructions for changing text, prices, images and metadata. Define how updates, error monitoring and recovery will work. The website evolves with the company's offer, so it helps to have a separate plan for technical maintenance.

Checklist selections are not saved after a reload. Record the results and evidence in your project log.

Questions about building a website that converts