Topical maps for dual optimization.

The surfaces are different documents.

Google shows a ten-blue-link page. An answer engine produces a generated answer with citations. These look like the same problem. They are not.

A page that ranks number one on Google for "how to write a security handbook" probably has 2,500 words, a clear H1 and H2 structure, internal links to related cluster pages, a last-updated date, and content that is comprehensive enough to satisfy a searcher who clicks and reads.

A page that gets cited by ChatGPT for the same query looks different. It probably has a short definition in the first 60 words that reads like an encyclopedia entry. It has a list of specific, numbered claims with sources. It has tables of comparable data. It reads like a reference document, not a blog post.

Both can be the same URL. But only if the document is structured to satisfy both readers at once, which is a deliberate design choice, not an accident.

What Google rewards, concretely.

Ignore the folklore. What we consistently see rewarded in 2026 is four things, with weights we can estimate from our own tracked corpus.

Topical depth inside a cluster. A site that has one page on a topic ranks worse than a site that has a pillar page plus eight to fifteen supporting articles on subtopics, all internally linked. The depth signal is measurable: we track pages that join clusters and watch their rankings climb within six to twelve weeks as the internal links mature.

Genuine expertise signals in the content itself. This is E-E-A-T operationalized. A bylined author with a real bio. A reviewer or editor named. A correction history. Dated content. Specific numbers that could only come from running the thing. The opposite of the bland AI-generated content flood, which is why Google keeps promoting pages that have obvious operator fingerprints.

Engagement after the click. We cannot see Google's internal metrics but we can see our own: bounce rate, time on page, scroll depth, return visits. Pages that rank are pages that people read. Pages that do not get read do not hold their rankings. This is why the "pump out 50 thin pages a week" strategy has a shelf life measured in months.

Structural clarity. H1 and H2 that match what the page is about. Schema.org markup. A table of contents on long pages. These are not ranking factors on their own but they make it easier for Google to parse the page, which is a prerequisite for everything else.

What answer engines reward, concretely.

The citation logic is different. An answer engine is looking for claims it can stand behind. It wants passages it can quote.

Quotable units. The atomic ranking unit for answer engines is not the page, it is the passage. A page that has fifteen self-contained, two-to-four-sentence units that each make a specific claim is more likely to get cited than a page that has the same total information structured as narrative paragraphs. The engine is scanning for quotable chunks.

Claim-evidence-source density. Every claim paired with a number, a date, an attribution, or a source makes the passage more citable. A claim without evidence reads like opinion. Opinion is cited less than fact.

Definition-first structure. The first 40 to 80 words of a section that defines a term in neutral, quotable language gets cited disproportionately often. It is the encyclopedia-entry effect. If someone asks Claude "what is a topical map" and your page opens with a two-sentence definition, you are in the candidate set. If your page opens with "Let me tell you a story about when I first encountered topical maps," you are not.

Original data. Answer engines love to cite numbers that have a clear provenance. A survey of 400 customers, a benchmark of 1,200 queries, a cost model run across 50 scenarios. The raw number pulls the citation because the engine needs a source for the number it is quoting. Our own share-of-answer-400-queries essay is cited more than any of our longer narrative pieces, because it has a dataset attached.

The three-layer topical map.

Our topical map has three layers: hub, spokes, and citation surfaces. Each layer is optimized for a different purpose. They interlink deliberately.

Layer 1: hub. The pillar page. One URL. 3,000 to 5,000 words. Comprehensive. Covers the full topic area. This is the page that ranks in Google for the broad head term. It is structured to be read linearly by a human who landed from a SERP.

Layer 2: spokes. Eight to fifteen supporting articles. Each covers one subtopic in depth. 1,500 to 3,000 words each. Each links back to the hub; the hub links to each. This is the cluster depth that tells Google the site has real coverage of the area.

Layer 3: citation surfaces. Short, dense, reference-style documents. 500 to 1,200 words. Every paragraph is a quotable unit. Heavy on claims, numbers, and sources. Often structured as lists, tables, definitions, or FAQs. These are the pages that get pulled into answer-engine responses. They do not try to rank in Google; they try to be cited.

The hub is the anchor. The spokes build topical authority. The citation surfaces capture answer-engine traffic. All three are needed because each surface rewards a different structure.

The hub, written for both.

The hub is the one page where both optimizations need to coexist. It is also the page most teams get wrong, because they optimize it for one surface and undermine the other.

Our hub template has six parts, in order:

Part 1, the definition block. 40 to 80 words, directly below the H1. Defines the topic in neutral, quotable language. No "let me start with a story." No preamble. If an answer engine pulls a citation from this page, it is almost always from this block.

Part 2, the key claims. A short list of three to five bulleted claims about the topic. Each claim has a number or source attached. This is the second-most-cited section.

Part 3, the narrative section. Here is where you write for the human who landed from a Google SERP. Longer form, narrative structure, examples, voice. Google parses this as the depth of the page. Answer engines mostly skip it for citations.

Part 4, the structured reference. A table, a comparison, a decision tree, a labeled diagram. Highly quotable. Highly shareable. Functions on both surfaces.

Part 5, the FAQ. Six to ten real questions with crisp, 60-to-150-word answers. The FAQ section has carried more answer-engine citations in our tracking than any other section on our hub pages. Every question is a candidate citation target.

Part 6, the related cluster. Internal links to every spoke page in the cluster. Plus links to citation surfaces. This signals topical depth to Google and gives answer engines more quotable documents to crawl.

Spokes: the depth layer Google wants.

A spoke is a narrative article. It has a point of view. It tells a specific story. It goes deeper than the hub on one subtopic.

Spokes are where your operator voice lives. A spoke reads like an essay, not a reference entry. It is the layer that defends against the AI-content commoditization problem, because an AI-generated spoke on the same subtopic will be visibly blander, less specific, and less evidentiary. A spoke written by someone who has actually shipped the thing has fingerprints that are hard to fake.

Spokes rank in Google for long-tail queries. They do not get cited by answer engines as often, because their structure is narrative. That is fine. Spokes earn their place by carrying topical depth and by capturing long-tail search traffic that never reaches the hub.

The spokes we see work best have four properties. They open with a concrete observation, not an abstract claim. They have a clear thesis stated in the first 200 words. They contain at least one piece of original data or evidence. They close with a link back to the hub and a link forward to a related spoke.

Citation surfaces: the claim-density layer.

Citation surfaces are the layer most teams have never built. They are reference documents, and they look boring. They are also the highest-leverage thing you can publish for answer-engine visibility.

Formats that work:

Glossary entries. One term, one URL. Definition in the first paragraph. Examples in the second. Related terms linked at the bottom. If someone asks an answer engine "what is a topical map," a glossary page with that exact term as the H1 is the highest-probability candidate.

Benchmarks. Numbers with methodology. "We ran X queries across Y engines. Here are the results." Must disclose methodology so the data is trustable. The 400-query share-of-answer dataset is a benchmark. It gets cited because the methodology is transparent and the data is otherwise unavailable.

Comparison tables. Three or more things compared on five or more attributes. These are highly quotable because the engine can pull a single row or column as a citation target. They rank in Google as well if the comparison is useful and the data is specific.

Checklists. Numbered items. Each item has a short rationale. Checklists are cited when users ask "how do I X" and the engine needs to surface concrete steps. Our OWASP LLM Top 10 audit checks essay is structured this way, and it is cited more than any narrative security essay we have.

Q&A collections. Six to twenty questions. Each answer is 80 to 200 words. Each question is phrased as users would actually ask it. These pages show up in answer-engine citations at a higher rate per thousand words than any other format we publish.

Failure modes on each surface.

Most dual-optimization attempts fail in one of three specific ways. Watch for these.

Failure mode 1: the single-voice hub. The team writes the hub as either pure narrative or pure reference. Pure narrative gets cited poorly by answer engines. Pure reference ranks poorly in Google because it reads as thin content. The hub needs both voices, separated into the six-part structure above. Trying to merge them into one voice ends with an awkward hybrid that works on neither surface.

Failure mode 2: no citation surfaces at all. The team builds a hub and spokes and calls it a topical map. Nothing gets cited by answer engines. The team concludes "GEO does not work for us." It does; the team did not build the layer that GEO actually rewards. Citation surfaces are not optional if you want answer-engine visibility.

Failure mode 3: citation surfaces with no original data. The team builds glossary entries and comparison tables. The tables reuse numbers from other people's reports. The answer engine could cite anyone for those numbers; it often chooses the original source instead. Citation surfaces need original data to consistently win the citation.

The fix in each case is the same: publish something nobody else has. One piece of original data per quarter beats fifty thin pages.

How we measure.

A dual-optimization topical map needs dual-surface measurement. Running Google Search Console in isolation misses half the picture.

For the Google surface we track: impressions per page, clicks per page, average position for tracked queries, and the cluster-level growth trend (sum of impressions across all pages in the cluster).

For the answer-engine surface we track: citation count per page across Claude, ChatGPT, Perplexity, and Gemini, measured monthly against a fixed panel of 100 to 400 tracked queries. We track which page and which passage got cited, which gives us a feedback loop on which citation-surface formats are paying.

After three months of tracking, the topical map will sort itself into clear winners and losers on each surface. The winners on Google are often narrative spokes. The winners on answer engines are almost always citation surfaces. This is not a failure of the strategy; it is the strategy working.

If the same page is winning on both surfaces, you have found something rare: a dual-optimized document. Over a year of publishing, we see maybe two or three per topical map that hit both surfaces simultaneously. Do not expect every hub to be one. Expect every hub to be decent on both while your citation surfaces carry the answer-engine load and your spokes carry the long-tail SERP load.