Published: October 14, 2026
Last Updated: October 22, 2026
An answer engine can cite a page only if the page already says the thing, in HTML, in an order a machine can follow. Design still has to persuade a person. It also has to survive being read by a system that never sees the mockup. Retrieval first web design is how we build for both, and it is the design standard behind the Engineer step of our CITE Method.
This guide is written by Stephen Prager, founder of Prager Microsystems in Collegeville, Pennsylvania. It is the markup and layout contract we use on WordPress sites that need to rank, get quoted in AI answers, and still convert. If the HTML response does not contain the answer, no amount of motion, 3D, or personalization will put your name under someone else’s response.
Two readers, one page
The person scans. The answer engine quotes.
The person
The answer engine
Quotable sentenceThe answer is in the HTML.
Retrieval first web design means the page is written and structured so a machine can retrieve, extract, and attribute it before any visual treatment is allowed to replace that text. The layout can be expressive. The HTML cannot be empty.
We use four working terms on every build. They are design constraints, not slogans.
The retrieval stack
What has to exist before the visual layer.
Traditional design reviews ask whether the page looks finished. A retrieval review asks a blunter question. If we deleted the stylesheet and the JavaScript, would a careful reader still know who we are, what we claim, and what to do next? If the answer is no, the design is not finished.
Every public page now has two readers. One is the person who might become a customer. The other is the systems that summarize the web on that person’s behalf. Those systems include Google AI Overviews, Google AI Mode, ChatGPT, Copilot, Perplexity, Gemini, Claude, and the voice assistants that speak a single answer.
The person scans. They respond to hierarchy, contrast, photography, and whether the next step is obvious. The machine does not experience any of that as design. It receives a response from a server, follows links, reads headings, lists, tables, and attributes, and decides whether a passage is safe to repeat with your name attached.
Designing only for the person was reasonable when the path to a customer was a list of links. It is a leak now. A homeowner can ask an assistant which company serves their town and never open the ten blue links. The firms that get named are the ones whose pages were easy to quote and whose business was easy to tell apart from everyone else using the same words.
This is not a reason to make ugly websites. It is a reason to stop hiding the useful parts. A strong headline, a real photograph, and a clear service area still matter because the person who does click has to trust you in a few seconds. Those elements earn the click. Clean structure earns the citation that creates the click, or that wins the job even when there is no click.
At Prager, answer engine optimization runs on the CITE Method. Clarify the entity. Inform with extractable answers. Trust with evidence. Engineer retrieval. Retrieval first design is how we engineer retrieval in the theme, the templates, and the page itself.
Clarify is a business problem. The same company name, the same address, the same services, and the same founders have to show up wherever a system might assemble a picture of you. Inform is a writing problem. Each URL owns a question and answers it in the first screen of text. Trust is an evidence problem. Specifics, authorship, and a trail of consistent public facts beat adjectives. Engineer is a design and development problem, and it is the one teams skip because it does not look like marketing.
Engineering retrieval means the theme outputs semantic HTML, the important copy is in the post or the template and not in an image, structured data matches the visible text, and the page is fast enough to be fetched completely. We treat that as design work. A developer who “makes it pixel perfect” by exporting the hero as one picture has undone the strategy, even if the screenshot looks right in a deck.
Search engine optimization, answer engine optimization, and generative engine optimization are not three websites. They are three jobs done by the same pages. SEO still needs a crawlable, indexable URL that matches the query. AEO needs a passage that can be lifted as the answer. GEO needs the page to be worth synthesizing because it contains a position, a method, or a fact that is actually yours. Content strategy decides which questions deserve a URL. Design decides whether that URL can be read.
If you want the description of the service of how we run the program, it lives on our answer engine optimization page. The definition of AEO and our content strategy practice cover the editorial side. This article is the build side.
The first HTML response should already contain the title, the answer, the headings, the primary facts, and the links. Anything that appears only after JavaScript runs is optional decoration, not the page.
We still use JavaScript. We do not use it as the place where the meaning lives. Marketing sites built as empty shells, with the copy injected after hydration, raise answer cost for no benefit a service business can feel. The model, the link preview, and sometimes the crawler all see the shell. The customer sees a spinner. Neither outcome is a design win.
On a WordPress site this is mostly a template decision. The header, the H1, the intro, the service list, and the footer business details should be printed by PHP into the document. Interactive pieces, a calculator, a gallery, a chat launcher, can boot afterward. If a number matters, the final number is in the HTML. A animation that counts up may decorate it. It may not be the only copy of it.
We also keep the response small enough to arrive quickly. Heavy hero video, uncompressed images, and a stack of tags that all want to run before the first paint are design choices, and they are usually the wrong ones. Our ceilings are practical. Largest Contentful Paint stays within 2.5 seconds. Interaction to Next Paint stays within 200 milliseconds. Cumulative Layout Shift stays at or below 0.1. Those are the floors a page has to meet before we will call the visual work done. Hosting is part of that floor. A beautiful template on a crowded shared server still loses. That is why managed hosting sits next to design in our builds, not in a separate conversation after launch.
Use one H1 that states the page’s job, then H2s written as the questions the page actually answers, in an order that still makes sense as an outline. Do not skip levels, and do not fake headings with bold paragraphs or styled divs.
A heading is a label a machine can read, not a font size. When a designer needs a label that is not a new section, we use a paragraph, a figure caption, or a real list. When a section answers a question a customer would type, the H2 is that question, in plain language. “Our approach” is weaker than “How does design fit the CITE Method?” because the second one can be matched to a query without guesswork.
The outline should stand alone. Read only the H1 and H2s out loud. If they sound like a table of contents a stranger could use, the structure is working. If they sound like “Overview / Solutions / Why us / The difference,” the page is organized around the company’s mood, not around retrieval.
We put an id on each H2 and a table of contents that links to those ids. The links help a person jump. They also create an explicit map of the document. The ids stay stable when we revise the prose, so citations and internal links do not rot every time a sentence changes.
Each major section opens with one or two sentences that answer the heading completely, then the section earns that answer with detail. The first sentences are the passage we expect to be quoted. The rest is for the person who wants the reasoning.
An extractable answer has three properties. It names the thing being defined, so it does not depend on a pronoun in the previous block. It takes a position, so there is something to cite other than a hedge. And it is short enough to repeat without chopping the grammar in half. We usually bold that passage on the page, inside a callout, because the person scanning is the same person the machine is trying to help.
Then we support it. Lists for steps and requirements. Tables when two or more things should be compared on the same attributes. Definition lists when we are naming a term we want associated with our firm. Paragraphs when the point needs a sequence. Those are not aesthetic preferences. They are the formats a system can lift without inventing structure you did not provide.
Here is the pattern we actually ship. The tags are the design.
<section id="response-time"> <h2>What has to be in the first HTML response?</h2> <p><strong>The first HTML response should already contain the title, the answer, the headings, the primary facts, and the links.</strong> Anything that appears only after JavaScript runs is optional decoration, not the page.</p> </section>
Compare that with a hero where the only H1 is a transparent PNG, the subhead is a Lottie file, and the “paragraphs” are divs positioned absolutely with no heading levels. A screenshot of the second version can win a design award. A retrieval pass gives it nothing to quote. We will not launch the second version.
Say who is speaking, in text, on the page, with the same name and facts you use everywhere else. A model cannot attribute a method to a firm it cannot tell apart from the template the firm bought.
Entity clarity is a design surface. The footer is not fine print. It is where we print the legal name, the street address, the primary phone, and the services, as text. The byline is not a vanity line. It tells a system that a person with a public history is responsible for the claims. Stephen Prager founded Prager Microsystems in 2003 and still works from the Collegeville office at 3819 Germantown Pike, Suite A, Collegeville, PA 19426. That sentence is deliberately dull. Dull, consistent facts are how a business becomes a thing a model can point at.
We align the visible facts with structured data, and we do not let the structured data say something the page does not say. Organization, Article, Service, FAQ, and LocalBusiness markup are labels on the content, not a second, secret website. If the FAQ schema promises a question the page does not display, we delete the schema. Hidden contradictions are a trust problem, and trust is the part of CITE that no template can fake.
Authorship also means the page has to contain something that is ours. A method with a name, a build standard, a specific recommendation tied to the kind of client we actually serve. Rewriting the same industry consensus in smoother prose does not give anyone a reason to cite Prager instead of the next agency. Retrieval first design, answer cost, text parity, and the way we tie them to CITE are ours. We publish them so they can be quoted with the name attached.
Any treatment that puts the meaning in a picture, a script, or a motion sequence, and leaves the HTML without it, makes the page harder to cite. The usual offenders are text in images, copy that exists only in the browser, fake headings, and pages that only make sense after a scroll hijack.
Text parity
Same page. One of these can be cited.
High answer cost
Text parity
Headline is real text
The sentence under it can be lifted without the picture.
Image sits beside the factsNext step
| Choice | What the person experiences | What retrieval gets | What we do instead |
|---|---|---|---|
| Headline set as an image or video | A controlled, line that matches the brand | No headline, or a filename | Real text over the media, with the same words |
| Copy injected by a front end framework | A page that appears after a spinner | An empty document | Render the words on the server. Hydrate the behavior. |
| Statistics that count up | A sense of motion | Zero, if the final value is not in the HTML | Print the final value. Animate only as an enhancement. |
| Divs styled to look like headings | The right visual size | No outline | H2 and H3 elements, styled with CSS |
| Carousel of key facts | One idea at a time | Often only the first slide, sometimes none | A list or table of every fact, with motion as optional |
| Infinite scroll as the only way to reach the answer | A long, dramatic page | A question with no reachable answer | Answer first. Let the story continue underneath. |
| Icon plus no label | A cleaner row, if the icon is obvious | A meaningless symbol | Visible text. The icon is support. |
None of this bans craft. We still use photography, motion, and the occasional three dimensional view when it helps someone understand a physical product or a space. The rule is text parity. A 3D model of a roof is a useful way to look at a roof. The material, the price range, the service area, and the next step stay in HTML next to it. If the model fails to load, the page still makes the offer.
Accessibility and retrieval are the same construction job more often than teams expect. Real headings, labeled controls, captions, sufficient contrast, and respect for reduced motion settings help a person who is not using the page the way the designer imagined. They also produce the explicit document a machine needs. We do not bolt that on at the end. A page that only works for one kind of vision, one pointer, and one fast laptop was never a finished design.
Personalize the emphasis, not the facts, and render a complete default on the server. A page that has no stable version cannot be quoted, cached, or trusted.
There is a real use for a page that leads with a different proof depending on whether someone arrived from a local service query, a paid ad, or an article. We will change the order of sections, the example, or the call to action. We will not maintain two contradictory descriptions of the company, and we will not require a script to assemble a sentence that should have been HTML.
The default response, the one a crawler and an answer engine receive with no cookies and no prior visit, has to be the full argument. Variants are layers on that document. If a test needs a different hero, both heroes exist as text. The stylesheet or a small script chooses which one is prominent. The other one is not deleted from the document in a way that leaves the response blank.
The same rule covers location pages. A dynamic local page is useful when the town, the service, and the proof are specific and true. It is useless when only the city name changes inside a paragraph that could describe any company in any state. Specificity is a design and content decision together. Thin duplicates raise answer cost for the whole domain because they teach a system that your URLs are interchangeable.
The theme should emit a short list of meaningful elements, with classes for appearance and almost no divs that exist only to satisfy a page builder. If we cannot explain why a wrapper is there, it does not ship.
We build most client sites on WordPress because the content model matches how marketing teams actually work, and because a carefully built theme can print semantic HTML without a JavaScript detour. Clean does not mean primitive. It means the document outline, the landmarks, and the text are obvious in view source.
Page builders are where this usually breaks. They can be configured to output reasonable markup, and they can also output seven nested containers for a single sentence. We judge the output, not the brochure. If view source reads like a spreadsheet of generated class names and the sentence is buried, we rebuild the template. Our web design practice is built around that standard, on purpose, because the firms we work with cannot afford a site that only looks correct in one browser window.
Performance is the other half of clean. A page that is semantically perfect and three times heavier than it needs to be still loses the person and wastes the crawl. We design the media, the font loading, and the third party stack at the same time as the layout. Ornament that costs a second and does not teach anything is cut. That is a creative decision. Restraint is part of the craft once anyone can generate a polished screen in a minute.
We launch when the page passes a retrieval audit. The answer is in the raw HTML, the outline matches the questions, the entity is consistent, the facts are visible, and the performance floors hold on an ordinary phone. A visual QA pass is necessary and not sufficient.
The audit is short. We run it on the URL, not on the design file.
That last step is a check, not a superstition. Citation also depends on whether the wider web agrees you are who the page says you are. Design cannot fabricate a reputation. It can remove the mechanical reasons a deserved reputation never gets quoted. The rest is the Clarify and Trust work. That means consistent profiles, real authorship, and proof that is specific enough to repeat.
When a site fails this audit, we do not start with a new color story. We repair the document. Then we design the surface on top of a document that can stand by itself. That sequence feels slower in the first week and it is faster over the life of the site, because the pages remain quotable after the visual trend that inspired them has moved on.
Open any question. The full answer is in the HTML either way, so a person can skim and a machine can still quote it.
Retrieval first web design is Prager’s build standard for pages that must be readable by people and quotable by answer engines. The HTML rendered on the server carries the claims, the structure, and the next step. Visual design organizes that text and is not allowed to replace it.
It is the engineering and design half of answer engine optimization, not the whole discipline. AEO also includes which questions you choose to own, how the brand is described across the web, and whether the evidence is strong enough to repeat. Retrieval first design is how the website itself stops blocking that work. We run the full program as the CITE Method.
Yes. Clean HTML rendered on the server is still how a page gets crawled, understood, and ranked. Answer engines did not replace that requirement. They made the cost of sloppy markup higher, because a page can now fail in the classic results and fail to be quoted. Speed, internal links, and a document that matches the query remain the foundation. Our search engine optimization work and this design standard are one build, not two vendors.
Usually no. A service business site should render its meaning on the server. Use JavaScript for behavior that HTML cannot provide, such as a configurator or a validator, and keep a complete default in the response. An application shell with no content is a high answer cost by default.
Images help when they add proof and the same facts also exist as text. They hurt when they are the only place a claim, a price, a phone number, or a headline exists. Write the alt text as a description of the information, and do not stuff it with phrases you wish you ranked for.
No. Schema is a label, and a label cannot cite a sentence that is not on the page. We add JSON LD after the visible content is correct, and we keep the two in agreement. FAQ markup without a visible FAQ, or a review markup the page does not show, is a contradiction, not an advantage.
Yes, as long as the default HTML is complete and the variants do not contradict the facts. Change emphasis, examples, and calls to action. Do not create a page whose only version of the offer appears after a script identifies the visitor.
Start with the URLs that already earn attention and make their answers extractable. Put the answer in the first HTML response, repair the heading outline, add text parity to the hero, and get the performance floors under control. Then extend the same template rules to the rest of the site. A redesign that begins with a new typeface and ends with the same empty markup will not change who gets cited.