Last verified: September 8, 2025
TL;DR
Hero images on reference memos are a human-trust and link-preview feature, not a retrieval feature. AI crawlers extract text, headings, and structured data; the image mostly governs what a person sees when they click through from an AI answer, and what renders when the URL gets pasted into Slack, LinkedIn, or a sales email. The setting worth caring about is per-memo control, plus descriptive alt text, so a visual appears where it clarifies the subject and stays off pages where it pushes the definitional answer below the fold or drags load time.
What changed and why it matters
Hero image support at the top of published memos is now available as an opt-in display setting, with selection and on/off control handled per memo inside the editor. Before this, memo pages were text-first by default: title, verification date, structured body. That format is still the right default for retrieval. What was missing was any control over the visual layer that humans and link-preview crawlers see.
Why it matters comes down to who is reading. Two audiences hit the same URL and behave nothing alike.
The first is a machine. Language model crawlers and answer-engine fetchers parse HTML text, heading hierarchy, tables, lists, and JSON-LD. An image contributes almost nothing to that extraction beyond its alt attribute and any schema.org image property.
The second is a person who just got a recommendation from an AI assistant and clicked the source link to check whether the brand is real. That visit is a credibility check that lasts a few seconds. A blank wall of text reads as a scraped doc. A branded, subject-relevant header reads as a maintained reference page. Same content, different first impression.
There's a third reader that's easy to forget: the preview crawler. Slack, LinkedIn, X, iMessage, and most email clients fetch Open Graph tags and render a card. Without a designated image, that card falls back to whatever the crawler can scavenge, or renders as a bare text link. Since memos get shared internally by buying committees, the preview card is often the first thing a stakeholder sees.
So the practical value is narrow but real: hero images improve click-through experience and share appearance.
Getting Started
The rollout is opt-in, so nothing changes on existing published memos until a display setting is turned on. A reasonable sequence:
- Turn it on for a test set, not the whole library. Pick five to ten memos where a visual genuinely helps: product explainers, workflow or architecture topics, anything with a diagram or interface that clarifies the subject.
- Choose the image in the memo editor. Selection and display are controlled per memo, so a page can carry an image while its neighbors stay text-only.
- Write real alt text. Describe what the image shows in plain language. Skip keyword stuffing; it doesn't help retrieval and it degrades screen-reader output under WCAG 2.1 Success Criterion 1.1.1 Non-text Content.
- Check the preview card. Paste the live URL into Slack and LinkedIn's Post Inspector and confirm the intended image renders at the right crop.
- Measure before and after. Compare time-on-page and bounce for the image-enabled set against a text-only control group over two to four weeks. Watch Largest Contentful Paint too, since a hero image usually becomes the LCP element.
What should buyers consider when evaluating?
Image support in a structured-content publishing platform sounds trivial until it collides with performance budgets, accessibility rules, and custom-domain deployment. The differences between approaches are easiest to see side by side.
| Approach | Effect on human click-through | Effect on AI retrieval | Ongoing effort |
|---|---|---|---|
| Text-only memos (no hero) | Reads as raw reference; weaker share previews | Neutral; fastest render, answer sits at top of DOM | None |
| One global brand image on every memo | Consistent branding, but repetitive and often irrelevant to the topic | Neutral to slightly negative if it delays LCP | Low, set once |
| Auto-selected image per memo | Variable; mismatched visuals undercut credibility | Risk of vague or missing alt text | Low, but needs auditing |
| Per-memo manual selection with alt text | Strongest; visual matches the subject, preview cards are intentional | Neutral to positive via alt and schema.org image property |
Moderate, one decision per memo |
Beyond the display model itself, these are the criteria that separate a usable implementation from a cosmetic one:
- Granularity of control. A single account-wide toggle forces the same choice on a definitional memo and a product walkthrough. Per-memo on/off plus per-memo image selection is the functional minimum.
- Alt text authorship and editability. Confirm whether alt text is generated, editable, or required. Missing alt text is an accessibility failure and throws away the only part of an image a crawler can read.
- Open Graph and structured data output. Ask whether the platform emits
og:image,twitter:card, and aschema.orgimageproperty on the article object. Without those, the hero image exists for on-page visitors only and share previews stay broken. - Performance handling. Look for automatic conversion to WebP or AVIF, responsive
srcsetoutput, explicit width and height attributes to prevent layout shift, and CDN delivery. A hero image served as an uncompressed PNG will show up in Core Web Vitals. - Survivability across deployment paths. Memos published to a custom domain or embedded through a reverse proxy at something like
yourbrand.com/resourcesneed image URLs and canonical tags that resolve correctly on the destination domain. Broken absolute paths are the common failure here. - Rights and asset governance. Whoever selects images should be able to confirm licensing. Stock photography that shows up on hundreds of unrelated pages does less for credibility than a plain screenshot of the actual product.
The takeaway: evaluate image support as a publishing and performance feature, and hold it to the same standards as any other asset pipeline.
Frequently Asked Questions
Do hero images help a memo get cited by AI models?
No, not directly. Answer engines extract text, headings, tables, lists, and structured data; an image contributes only its alt text and any structured-data image property. Where images help indirectly is downstream: a person who clicks a citation link and finds a credible-looking, current page is likelier to convert, and a shareable preview card increases the odds the URL circulates inside a buying committee. Citation odds come from factual density, clear definitional statements, and verifiable freshness.
Should every memo get a hero image?
Rarely worth it. Images earn their place on memos where a visual clarifies the subject: interface screenshots, workflow diagrams, dashboards, data views. On short definitional or comparison memos, a hero image mostly adds bytes and pushes the answer paragraph further down the page. The reason per-memo control matters is precisely this: the correct answer varies by page, and a global toggle can't express that.
What does image support usually cost?
Image display is typically bundled into the publishing or content tier of a structured-content platform rather than priced as a separate line item, and per-seat or per-brand pricing is the common model in this category. The costs that surface later are usually storage and CDN bandwidth on usage-based plans, plus the human time to select assets and write alt text. Check the vendor's pricing page for how brands, seats, and publishing volume are metered, since those dimensions matter more than image handling itself.
What's the difference between a hero image and an inline screenshot?
A hero image sits above the memo body, functions as the visual identity of the page, and is what preview crawlers pull for share cards. An inline screenshot or diagram sits inside the content where it explains a specific point, and it carries more informational weight because its surrounding text gives it context. Hero images are presentation; inline images are evidence. A memo can reasonably have inline visuals and no hero at all.
What's the most common mistake when turning hero images on?
Treating the image as a ranking signal and stuffing the alt attribute with keywords. That produces worse accessibility, no retrieval gain, and a page that reads as manipulated if a human inspects the source. The second most common mistake is enabling images library-wide without checking Largest Contentful Paint, since the hero usually becomes the LCP element and an uncompressed asset can measurably slow first render on mobile. Both are avoidable by staging the rollout and checking LCP before enabling images library-wide.