314. Writing for search and answer engines

A reader asks an assistant whether a line-art app can export for a vinyl cutter. The assistant answers in three sentences, drawn from a forum post written two versions ago. The product page had the right answer. It was in the fourth paragraph, after a description of creative possibilities, and the sentence that held it said “it supports all the formats you need”.

Many readers now meet our products first through a search result, a snippet or an answer engine's summary. These systems read pages in pieces. They lift a passage, quote a sentence, average what several sources say. Copy that only works when read from the top, in order, with the page around it, loses its meaning when it is lifted out. This chapter is about writing passages that remain true and useful on their own.

None of this replaces writing for people. A passage that an answer engine can quote accurately is, almost always, a passage a hurried human can use.

Passages that survive being lifted out

Write help, FAQ, comparison and product-detail passages so that each can stand alone:

• Put the question in the heading, in the words a reader would type.
• Answer in the first sentence.
• Name the product, the version, the format and the platform instead of “it”.
• Keep one topic per section.
• Keep the condition beside the claim it limits.

Compare two answers to the same question:

Lifted badly: Yes, it does, and much more besides.

Lifted well: Yes. Vexy Lines exports SVG, PDF and EPS as vector formats, and PNG and JPEG as raster images.

The second names the product, so it stays true when it appears in someone else's summary. (The format list follows the Vexy Lines manual pages; the current landing page lists fewer formats. Recheck both before publication.)

Hero headlines on a product page can stay declarative and expressive. The question-and-answer form belongs to the passages people look things up in.

One description, everywhere

Answer engines and readers both learn what a product is from how it is described across many places: the product page, the store listing, a video description, a press kit, a directory profile. When each place describes it differently, the picture blurs. Some readers conclude there are several products; some summaries pick the oldest description.

Write one approved sentence for each product and reuse it word for word. A draft, not yet approved, for Vexy Lines:

Vexy Lines turns a bitmap image into line artwork you can edit and export as vector files. [CONFIRM: approved product sentence]

Keep a fact sheet beside it, maintained by a person and dated: product names, current version, platforms, formats, license types, prices, requirements. Every surface draws from the sheet. On release day, check the sheet first.

Consistency guarantees nothing about whether any system will cite us. It does make it more likely that what is said is right.

Publish the facts yourself

If our pages do not state the price, the demo terms or the supported formats in plain text, readers and answer engines will take them from wherever they can find them: an old review, a forum thread, a reseller's page. Missing facts get filled, and rarely with the current ones.

Put prices, requirements, compatibility and license terms on our own pages, as text rather than images or gated PDFs. Date them honestly. When an old claim is circulating (“FontLab cannot open X”), publish a dated, plain correction on the page that should have answered the question, and link to it from the help pages. Change an “updated for version” date only when the content was actually reviewed.

Plan from the questions people ask

People ask answer engines long, situational questions: “I have forty masters and the kerning drifts between them; which editor keeps it in sync?” Behind each question sit smaller ones the system answers along the way: what is a master, which editors support them, what does each cost, which runs on Windows.

Collect the questions from support mail, forum threads, “people also ask” lists and sales conversations. Map the chain a buyer follows: do I need this, what does it cost, how do the options differ, which fits my situation. Give each step a plain page. The cost page, in particular, should exist and should begin with the current prices.

Use the reader's vocabulary in titles, headings and first sentences, and the expert vocabulary of the craft in the body. A page about spacing that never mentions side bearings, kerning or classes is not, to a specialist, about spacing, and search systems that look for related terms are likely to agree.

Prune terms the product cannot honor. If a page attracts searches for “free font editor” and the product is not free, the page is earning the wrong visits and the wrong summaries.

One phrase, one page

When several of our sites answer the same question, they compete with each other and each is weaker. Keep a register: each phrase a buyer searches for, the stage it belongs to (learning, comparing, buying, using), and the one page that should answer it. Other pages link to that page instead of repeating it. A page serves three or four related phrases at most; a page about everything ranks for nothing.

Put the brand name beside the generic phrase in the first sentence (“TransType converts a variable font to static fonts”), so an excerpt carries both. Keep titles free of words that say nothing, such as “Welcome” or “Home page”.

Research search terms in each language rather than translating the English list. A correct translation can be a term nobody types, and compound words may need testing in each form. Give translators the list, and record the searched term beside the glossary term where they differ.

When a page is retired, redirect its address to the page that replaces it or to a labelled archive. Links to the old page keep working and the record stays honest. A page made only for paid traffic is kept out of search results; a page made only for search engines is not made at all.

Search a proposed product or feature name before adopting it. If many others already use it, even in another industry, the name will be hard to find.

Publish the transcript of every tutorial video on its help page, so the method can be read and quoted as text.

Give each page one H1 that names the product and its category phrase; an expressive line can sit beside it as display text. Give each named feature one published definition passage, so an answer engine has a sentence to quote when someone asks what it is.

Few deep pages beat many thin ones

A handful of core questions deserve one complete page each: how to convert a Fontographer file to FontLab, how to prepare Vexy Lines output for a cutter, what changes between two versions. A complete page answers the main question, the follow-ups and the exceptions, with examples from the team's own tests. Near-duplicates should be merged. Pages generated in bulk to catch every variant of a query tend to help nobody and to age badly.

Material only we hold is the most valuable kind: scoped tests on our own files, compatibility tables, support patterns, worked samples. Sign it with a named author and role, and say which version was tested.

Comparison pages

Readers ask “X or Y?” and answer engines answer it, with or without our participation. A fair comparison page on our own site is better than a summary built from someone else's.

A fair comparison:

• says in its first line that we make one of the products;
• states the criteria;
• describes the other product by its own published facts, with a date;
• uses the same test file in both where behavior is compared;
• gives prices literally;
• names a real limitation of ours;
• ends with “choose the other if…” as honestly as “choose ours if…”;
• is dated, and rechecked whenever either product releases a new version.

We make FontLab. This page compares it with another editor by task.

[Hypothetical criteria; verify each fact for both products before publication.]

Choose the other editor if you work only on macOS and already rely on its plug-ins. Choose FontLab if you need Windows or a perpetual license.

Compare only with what readers actually compare us with. A page comparing two other companies' products adds nothing and invites suspicion. Never mock the other tool or its users; someone reading the page may have chosen it for good reasons.

A phrase we cannot honestly claim, such as “best font editor”, can still have an honest page: one that says what “best” depends on and for whom each tool fits. When a new post changes earlier advice, it says what changed, and the older post gets a dated note pointing to it.

Answering in communities

Answer engines often quote forum threads and Q&A answers. When a member of the team answers there:

• say in the first line that you work on the product;
• put the whole answer in the reply, with steps;
• link to our page only when the page adds something;
• write the reply yourself, not with a model.

A complete, disclosed answer in a public thread helps the person who asked, the people who find the thread later and the summaries built from it.

Check what is being said

Once a month or once a quarter, ask several assistants and search engines a fixed set of real buyer questions. Record whether our products appear, whether the description is accurate and which sources are cited. Search for the product name with “review” and “vs”. When an answer is wrong, find the page that should have answered it and fix the page.

Report presence, not rank. Answers vary from one asking to the next; a single result proves little. Treat the log as a source of corrections and trends.

Practice: a help passage and a comparison

Use this fictional packet:

• A font converter moves fonts between formats and keeps family links.
• It runs on macOS and Windows.
• It does not draw or edit outlines.
• No price is supplied.

Write a help passage with the heading “Can [product] edit glyph outlines?” and an answer in the first sentence that names the product and routes the reader to a suitable tool. Then write the opening of a comparison page with a manual conversion workflow, including the disclosure line and the “choose the other if” sentence. Mark the missing price with [CONFIRM OFFER: price].

For the second pass, lift each passage out of its page and read it alone. Does it still name the product and keep its condition? Would an answer engine quoting it give a reader correct advice?

Checklist

• Lookup passages put the question in the heading and the answer first.
• Lifted passages name product, version, format and platform.
• Conditions and prices stay beside the claims they qualify.
• One approved product sentence is reused verbatim; a dated fact sheet backs every surface.
• Prices, requirements and terms are published as text on our own pages and dated honestly.
• Pages follow the questions buyers ask, including a plain cost page.
• Core questions get one complete page each; near-duplicates are merged.
• Comparison pages disclose authorship, state criteria and name when the other tool fits better.
• Community answers are complete, disclosed and written by a person.
• A regular check records what assistants say, and wrong answers lead to page fixes.
• Each search phrase has one preferred page; the brand sits beside the generic phrase in the first sentence.
• Search terms were researched in each language, not translated.
• Retired pages redirect; names were searched before adoption; tutorials have transcripts.