Why FAQ on Bitrix breaks search and conversion
The questions section on Bitrix is most often put together "quickly": one information block, one template, answers displayed via an accordion script.
On the surface it looks neat, but for search engines the page turns into a set of identical headings with no content — the answers are loaded in the browser and are absent from the source code.
The robot sees empty blocks, indexes them as low-value, and lowers the weight of the entire section.
The second typical mistake is duplicates. Each question gets its own URL, but the meta tags are inherited from the information block template: the same title, the same description, the same H1 heading.
For search, these are dozens of nearly identical pages that compete with each other and blur relevance. If pagination without canonical URLs is added to this, the number of duplicates grows many times over.
The third problem is the lack of structured data. Even when the answers are visible in the code, search does not understand that it is looking at a question and an answer, and does not show an enhanced snippet.
FAQPage markup removes this uncertainty: the search engine gets an explicit structure and can display the question directly in the results, taking the click from competitors before the user even visits the site.
Internal search suffers separately. The built-in module searches by an index, into which the content of the questions information block does not always make it — especially if the answer is stored in a separate property or loaded dynamically.
The visitor does not find the answer, goes to support, or closes the tab, even though the information is on the site.
The bottom line: a questions section that was intended to reduce the load on support starts working against the site — it loses rankings, does not get into enhanced snippets, and does not help the user find an answer.
Let's break down how this is addressed at the level of the information block structure, output templates, and indexing settings.
What a properly assembled FAQ section provides
A properly assembled FAQ section is not a "page with questions" but a managed source of traffic and a way to relieve the support team.
When questions are grouped by topic, marked up with structured data, and linked to product and service cards, search engines begin to show answers directly in the results — the share of clicks from search grows without additional investment in advertising.
At the same time, the number of support requests decreases: the customer finds the answer on their own, without waiting for an operator's response.
The FAQ structure on 1C-Bitrix is built so that each question is a separate entity with its own address, heading, and markup.
This produces three effects at once: pages are indexed for specific queries, snippets in the results take up more space, and internal links distribute weight between related sections.
Without such a structure, questions remain "dead" text that search engines barely take into account.
The speed of publication is a separate measurable parameter.
When the question template, fields, and markup rules are configured in advance, new material is published within minutes: the content manager fills out the form, the system generates the page itself, adds it to the sitemap, and links it to the relevant section.
On projects where this process is not automated, publishing a single question drags on for days and requires a developer.
As a result, the FAQ stops being an "add-on" to the site and becomes a working tool: it brings targeted traffic from search, relieves part of the load on support, and allows new information requests to be handled quickly. Next, we will look at how this is arranged at the level of structure and settings.
FAQ implementation options: comparison of approaches
On Bitrix, the questions section is assembled in four ways, and the choice is dictated not by "beauty" but by who will add questions and how often.
If the content is managed by an editor without access to code — one path; if rigid structure and automatic micro-markup are needed — another.
| Option | When it fits | Limitations |
|---|---|---|
| Information blocks | Dozens to hundreds of questions, regular edits, categories and filters needed | Requires configuring properties and templates; without customization, the output and markup "out of the box" are sparse |
| Static pages | 5-15 questions, rarely change, speed and simplicity matter | No search or grouping; as the number of questions grows, the page turns into a dump |
| Ready-made modules | Need a quick start with a ready-made interface and markup | Dependence on third-party code, limited customization, risk of conflicts during updates |
| Custom component | Non-standard logic: integration with requests, roles, multilingual support | More expensive to develop and maintain, documentation needed for the team |
What to consider when choosing
Information blocks are a workable compromise for most: the editor adds a question through the familiar admin panel, while the developer configures the template and micro-markup once.
Static pages are justified only at the start — migrating to an information block later will cost more than laying out the structure right away.
Ready-made modules save time at launch, but being tied to third-party code makes itself felt at the very first core update. A custom component is chosen when the FAQ is part of business logic, not just a text block.
Stages of setting up a turnkey FAQ section
Setting up an FAQ is not "install a component and upload questions." The section lives inside an information block, its pages compete for positions with other site materials, and the markup must match what the visitor actually sees.
That is why we work in stages, from audit to guidelines, so the section does not fall apart a month after launch.
- Audit of the current section. We look at what already exists: category structure, duplicate questions, broken pagination pages, template weight. We check whether question pages have been merged into one due to identical titles and canonical — this is the most common reason a section fails to get indexed.
- Data schema. We design the information block: separate properties for the question, answer, category, and display order, plus binding to catalog or service sections. At this stage we decide whether each question will be a separate page or an expandable block — all further logic depends on this.
- Component setup. We build the output using standard components with caching by category, configure pagination and human-readable URLs. We adjust the template so that the question and answer markup is delivered in the source code rather than loaded by a script.
- Markup and metadata. We write titles, descriptions, and structured data for rich snippets, and link the section via internal linking to relevant pages.
- Indexing check. We submit the sitemap, check robots and server responses, and see how search engines crawl question pages and whether service URLs end up in the index.
- Maintenance guidelines. We document who adds questions and by which template, how duplicates are checked, and where to make edits to the markup.
After the guidelines are handed over, the section can be filled by a content manager without touching the structure or breaking indexing. If you already have a questions section, we will start with an audit and show what is preventing it from working.
What is included in the deliverable: configuration and documentation
The result of the work is not a "ready-made Q&A section," but a set of settings and documents by which the section lives and evolves without us. Below is exactly what we hand over to the client.
- Infoblock settings: the structure of sections and subsections, element properties for a question and an answer, binding to topics, and permissions for adding and editing for each role.
- Output templates: list and detail page components, markup of the "question — answer" block, expand/collapse behavior, pagination, and display of related questions.
- Structured data rules: which markup type we place on the question page, where we place the block with answers, how we link questions to service sections, and how we validate before publishing.
- Section map: a list of all questions with binding to infoblocks, templates, and page URLs — it shows where to add a new question and what it will affect.
- Editor's guide: the step-by-step procedure for adding a question, requirements for the wording of the title and answer text, working with images and links, and what to do when moving a question to another section.
- Publishing policy: who approves the text, at what point the question gets into the markup, and how often we review outdated answers.
- Set of checks: control of duplicate questions, broken links inside answers, markup correctness, and page load speed of the section.
We hand over each item in a form suitable for work: settings — in the admin panel, templates — in the theme files, rules and instructions — in a document with examples. An editor without a developer adds a new question in a few minutes and does not break the section structure.
Case study: how the Q&A section stopped losing traffic
The project is a corporate website on 1C-Bitrix with a base of ~400 questions accumulated over the years.
The FAQ section existed, but worked like a dumping ground: questions were published manually through the admin panel, answers sat in a single template, every page had the same title, and there was no micro-markup.
Search engines barely indexed such pages, and some questions duplicated the content of the main sections.
What it was before
Out of 400 questions, about 90 were in the index — the indexation rate held at 22%. Search referrals to the section averaged 340 visits per month, with 80% of the traffic going to a dozen old questions.
A new question was published in 3-5 days: the content manager waited for an answer from the relevant department, then manually assembled the page and filled in the meta tags. Half of the questions stayed in drafts.
What was changed
We restructured it: each question got its own URL with a human-readable address, a unique title and description, as well as FAQPage markup — the search engine began showing the answer right in the results.
We added interlinking: links from the answer now lead to the relevant service pages, and from the service cards to related questions.
Publication was moved to a form: the manager fills in the fields, the question goes for approval, and after confirmation the page is assembled automatically.
What it became
The share of indexed pages grew from 22% to 87% — most of the questions made it into the index, including the old ones. Search referrals grew from 340 to 1,900 visits per month, while the traffic was distributed across hundreds of pages rather than a dozen.
The publication time dropped from 3-5 days to a few hours: the bottleneck shifted from layout to text approval. Duplicates with the main sections were removed via canonical addresses, and the positions of the service pages only improved as a result.
How an FAQ in an information block differs from a static page
An information block stores questions as elements with fields and properties, while a static page is a single file where the markup and text live together.
Everything else diverges from there: how quickly you edit content, how flexibly it is rendered, and how search engines see it.
Editing speed is the first thing an editor notices. In an information block, a question is added through the administrative interface: fill in the fields, select the section, save — the element immediately appears in the common list and in the output on the site.
On a static page, every edit means working with a file: find the right markup block, avoid breaking the neighboring ones, save.
When there are dozens of questions and they are updated regularly, the difference accumulates — an editor without access to code works independently in an information block, while on a static page they wait for a developer every time.
Template flexibility is determined by where the output lives.
In an information block, the logic is moved into the component template: once you configure the markup, all new questions are rendered in the same form, and filters, sorting, and pagination are enabled through settings.
A static page offers no such reusability: to change the structure, you edit the markup manually in every place where it is duplicated, and it is easy to end up with discrepancies between pages.
Indexing depends not on the storage method but on what ends up in the final HTML.
An information block serves ready-made markup on the server, so search engine robots see the questions and answers immediately, and the FAQ structured data is generated in the template automatically for all elements.
A static page is indexed the same way, but with manual insertion the structured data has to be maintained separately in each block — and it diverges from the content at the very first edit.
The practical takeaway: an information block wins where the FAQ grows and is updated, while static pages are appropriate for a few unchanging questions.
A hybrid is often chosen — storage in an information block, with output on a separate page via a component with SEF URLs and pagination.
Common technical concerns about FAQ on Bitrix
The FAQ section on Bitrix rarely breaks "on its own" — usually it diverges from the rest of the site's infrastructure.
Questions and answers are stored in an information block, rendered through a component, cached together with the page, and at the same time participate in structured data and site search.
As soon as one of these connections is changed manually, duplicates, outdated answers, and pages that have dropped out of search results begin to surface.
Below are the technical concerns that most often bring people to us for support: how to mark up questions so they appear in rich snippets, how to configure caching so that an edit to an answer appears immediately, and how to migrate an accumulated base of questions from an old system without losing structure and URLs.
How to mark up questions so search engines can see them?
It is more convenient to generate structured data from the same information block that renders the section — that way the question and the markup don't diverge during edits.
We validate it through webmaster tools and make sure the markup isn't duplicated across paginated navigation.
Why does the old version remain on the site after editing an answer?
The component serves a cached page, and the cache lifetime isn't tied to changes in the information block element. We set up cache invalidation on change events and split the cache by user groups so that guests and authorized users see the current text.
How to migrate questions from an old system without losing URLs?
We assemble an export, map the fields, and migrate the questions into the information block while preserving the previous URLs through processing rules. We close the old pages with redirects so that accumulated search traffic doesn't go to waste.
What to do about duplicate questions in site search?
The cause is several pages with identical content or different phrasings of the same question being merged. We consolidate duplicates into a canonical page, configure indexing, and exclude service sections from search results.
Describe how your questions section is currently set up and what exactly concerns you — we'll get back to you with an estimate and a work plan.
Let's discuss your FAQ section task
To come back with an estimate and a plan rather than generalities, we need to understand how your setup works: which edition the portal runs on, how the section is structured now, and what exactly you want from the FAQ — a reference block for clients, landing pages for search queries, or a knowledge base for employees. This determines the structure of the questions, the markup, and the output method.
Send us whatever you have on hand — then we'll ask targeted, substantive questions:
- the site address and access to the admin panel or a test environment;
- a list of sections and page types where the FAQ should appear;
- a list of questions, if one has already been compiled — in a table, document, or export from inquiries;
- examples of reference pages whose look and logic you like;
- role requirements: who edits questions, who publishes, whether moderation is needed;
- constraints on deadlines and dates by which the section must be live;
- the contact of the person who accepts the result and answers content-related questions.
What you get at the end is not a set of files, but a working section and clear instructions for it: an agreed structure of questions and a rubricator, configured output with correct markup for search, page templates matching your layout, access rights for editors, and a short regulation on how to add and update questions on your own.
Handover takes place on a test environment: you check how the section behaves in your scenarios, we address the feedback, and only after that do we push it to the live site.
Describe the task in free form — what kind of portal it is, which section you need, and by what deadline. We'll come back with an estimate, a work plan, and a list of what we'll need from your side.