How We Shape an Article So an Assistant Can Restate It

What we mean by generative engine optimization

Generative engine optimization is the work of making a page easy for a language model to restate correctly. A model that answers a question lifts passages out of a page and rewrites them, so each passage has to keep its meaning when it stands alone.

We treat this as a format problem. On bbmmtech.com an article is a record with fixed fields, and the format decides where the quotable parts sit. Our article on answer engines covers the files we publish for crawlers. This one covers the shape of the article itself.

The article record

Every article on bbmmtech.com is one object of the BlogPost type, which has 14 fields. Three of them exist for extraction.

• tldr: a short summary that answers the article's question directly.
• keyTakeaways: a list of single facts.
• faqs: question and answer pairs.

Two more fields carry provenance. authorId points at an author record with a name, a role, a profile URL and a short biography. references is a list of labels, each with an optional URL.

Dates are separate fields as well. date and datetime hold the publication time, and updated holds the last revision. The page, the BlogPosting markup and the sitemap all read these fields, so they state one set of dates.

Six block types and three heading levels

The body of an article is an array of sections, and a section is a heading plus an array of blocks. The type allows six kinds of block.

• A plain string, rendered as a paragraph.
• h, a subheading.
• ul, a bullet list.
• ol, a numbered list.
• note, a callout box.
• quote, a block quotation with an optional citation.

An article contains no raw HTML. The renderer maps the title to h1, each section heading to h2 and each h block to h3. Heading levels cannot skip, and an author cannot pick a heading for its size.

Lists become real ul and ol elements. A parser that splits a page into passages receives each list item as an item.

Where the page puts each field

The article page prints each extraction field in its own region under a visible label. The order is fixed by the template.

1. 1.The publication date in a time element with a machine-readable datetime attribute, followed by the reading time and the tags.
2. 2.The title, then the author's name and role.
3. 3.The summary in a bordered box labelled In short, above the first section.
4. 4.The sections.
5. 5.The key points in a box headed Key takeaways.
6. 6.The questions under the heading Frequently asked questions, as a definition list with each question in a dt element and each answer in a dd element.
7. 7.The references, then a box about the author with the biography.

Reference links are marked nofollow. A citation is a pointer for the reader, and we do not present it as an endorsement of the target.

The summary and the key points are also what llms-full.txt prints for each article. The short form an assistant reads in that file is word for word the text on the page.

Pages we keep out of the index

A page with no text of its own gives a model nothing to restate, so we mark such pages noindex.

Tag pages on bbmmtech.com are lists of links to articles. Each one declares its robots value as noindex, follow and is left out of the sitemap. The follow value stays on so that the articles behind a tag still receive the link. A tag gets a page when at least two articles use it. At three it also becomes a filter chip on the blog index and a link on article pages.

The not-found page needs an explicit override. The root layout sets the home page as canonical and sets robots to index, follow, and a page inherits both unless it says otherwise. The not-found page sets its canonical to null and its robots to noindex. A missing URL therefore never names the home page as its canonical version.

The product sites follow the same rule. On textpack.app the page shown after a purchase is noindex, nofollow. On flowoapp.com the not-found page, the invite page and the store redirect pages are written with noindex, with no canonical link, and outside the sitemap.

Titles sized for the result and for the page

A title has two readers with different limits: the search result and the page. flowoapp.com gives each its own value.

A function fits each journal article's title to 60 characters and its description to 160. It tries the title with a long brand suffix, then with a short one, then with none, and keeps the first that fits. A description that runs over is cut at a word boundary. The article page keeps its full title and excerpt.

On bbmmtech.com the article title is used as written, with no site name appended, and the description field becomes the meta description.

The prerender script on flowoapp.com also rewrites the title, description, canonical link, Open Graph tags and Twitter tags for every page it writes. The comment in the script gives the reason: without the rewrite, every subpage would inherit the home page's canonical.

One text for readers and crawlers

A crawler and a person receive the same document on our sites. bbmmtech.com is exported as finished HTML, so the article a model fetches is the article a browser shows.

flowoapp.com is a React app, which makes this a deliberate step. Its guide pages and journal articles are prerendered by the React components that render them in the browser. The static HTML of the methodology page is generated from the translation strings the React page uses, so the two versions carry one text.