What IT Is

(and Why Your Meta Description Is Only a Suggestion)

TL;DR: If you are committed to making your site accessible, WCAG compliance is the minimum standard for successful SEO and GEO, so you are already most of the way there. GEO adds little new markup. It comes down to formatting and wording that read as authoritative on the topics your SEO strategy already targets, which is also what the search engines are judging, whatever your metadata says.

Three Topics That Refuse to Stay in Their Own Sections

I recently wrote an SEO, GEO, and accessibility guide for the content authors on a public website rebuild for a client in a highly regulated industry, where reputation matters. The plan was three tidy sections. That plan lasted about as long as the outline did. Every heading-structure rule in the SEO section turned out to be an accessibility rule as well. Every alt-text requirement in the accessibility section was also an SEO and GEO requirement. And the GEO section kept coming back to the same advice the SEO section had already given, just with stricter grading.

So the guide combined them. These are three views of the same work.

Accessibility Is a Line Item Until Someone Reads the Search Console Report

On most projects, the three topics go to three different owners. Accessibility is a compliance checkbox, usually handled by an audit near the end, when fixes cost the most. SEO belongs to marketing. Translation sits in a backlog labeled “phase two,” which everyone understands to mean “never.” Each group gets its own budget line, its own vendor, and its own status meeting.

That split hides the fact that all three groups are paying to fix the same pages.

Screen Readers and Crawlers Read the Same Page

A screen reader user navigates a page by its headings (see Headings (Page Structure Tutorial) from the W3C for how that works). Search engines use the same heading hierarchy to work out what a page is about, and AI systems use it to decide which chunk of the page answers which question. One H1 and a logical set of nested H2s and H3s serve all three audiences at once.

The same pattern holds across the rest of the checklist:

• Alt text is what a screen reader announces, and it is also what image search and AI systems index (see Understanding SC 1.1.1: Non-text Content). Make it a required field in the CMS and treat every image as meaningful. “Decorative” is where alt text goes to die.
• Descriptive link text (“Account Security Guide,” not “click here”) tells a screen reader user where a link goes and tells a crawler how your content connects.
• Captions and transcripts make video usable for deaf and hard-of-hearing visitors. They are also the only part of a video that a search engine or AI system can actually read. Publish the transcript as its own page and link it right next to the video or audio embed, where both people and crawlers will find it.
• PDFs with a real text layer. A scanned PDF is a picture of text. It is equally useless to a screen reader, a search engine, and an AI crawler, however well the original was written (see PDF Accessibility from WebAIM if you have a back catalog to audit). The fixes are simple:
  • Export PDFs from the source document (Word, InDesign, whatever made it) so the text stays selectable.
  • If a scan is the only option, such as a signed form, run it through OCR before publishing.
  • Before uploading, try to select a sentence or Ctrl+F for a word you know is there. If you can’t, it needs OCR.

The machines are the most demanding assistive-technology users you will ever have. They cannot see your layout or infer meaning from color, and they won’t ask a colleague what that unlabeled icon does. Meet WCAG 2.2 AA for the humans, and the crawlers get a page they can parse as a side effect.

So WCAG is the “lowest common denominator”: the baseline every consumer of the page, human or otherwise, depends on.

One Investment, Three Returns

Accessibility work done properly pays for itself in compliance, search ranking, and AI visibility.

The clearest example from that rebuild was content in a second language. Missing translated pages were logged as an equity gap, and they were also a search visibility gap, because customers searching in their own language won’t find content that only exists in English. Closing it was one piece of work with two scorecards. The same goes for customers who can’t find the answer they came for and end up calling support instead. In a regulated industry, every one of those calls costs money and chips away at reputation. Every page that is easier to find and easier to read keeps someone out of the call queue.

Start With What People Are Trying to Do

Intent comes before keywords. Search behavior generally falls into four buckets (the first three come from Andrei Broder’s A Taxonomy of Web Search, which has held up well since 2002):

• Informational: “how to lower my monthly bill”
• Navigational: “account login”
• Transactional: “open a new account”
• Referral: typing a URL from a printed statement or an ad, or following a link from another site or a search result

Map each page to the intent it serves. A page that tries to serve the first three at once usually serves none of them well. Referral traffic has its own rule: the landing page has to match the context of wherever the link appeared, or the visitor bounces and the link does nothing for you.

From there, research the actual terms each audience uses, including FAQs, high-intent searches, evergreen topics, and gaps where other sources rank and you don’t. Group related terms into topics and map each topic to one page, existing or new.

For existing pages, check how they perform before rewriting anything:

• Which pages already get traffic
• Where rankings are close, around positions 5 to 20, which are usually the easiest wins
• Structural problems holding a page back, such as broken heading order, missing alt text, or content sequenced for the org chart instead of the reader
• Content gaps compared to other sources on the same topic

The Search Engine Has Its Own Opinion of Your Page

Too much focus on SEO metadata mostly leads to frustration. Google and Bing put far more weight on their own analysis of a page than on the metadata you hand them. Your title and meta description are suggestions, and the engines treat them that way.

While putting that guide together, I ran a quick check on one page. A loosely phrased search on Bing returned the page with a snippet that matched the meta description word for word. Gold star. Google returned the same page with a description it had written itself. So I searched again, this time using the exact text of the meta description. Google came back with yet another description, assembled from content halfway down the page. Bing didn’t return the page at all, though it did find a few similar pages on the same site.

Two engines, two searches, four different outcomes, and the carefully crafted meta description showed up exactly once.

Google says as much in its own documentation: it may build a snippet from page content when that better matches the query (see How to Write Meta Descriptions). So write good metadata, then stop polishing it. The hours spent tuning a 155-character description are better spent making the page body say the right thing clearly, because that is the text the engines are reading.

The Unglamorous Basics Still Pay Rent

The fundamentals still matter. They are cheap and mostly one-time decisions, and skipping them leaves money on the table.

URLs

• Keep them lowercase, hyphen-separated, and human-readable: /contact-us, not /pg-4021 (see URL Structure Best Practices for Google Search).
• If a URL has to change after publishing, set up a permanent 301 redirect from the old one (see Redirects and Google Search). Otherwise you throw away the ranking and break every backlink pointing to it.
• During a migration, keep existing URLs wherever possible. A new site is not a reason to start search authority over from zero.

Titles and descriptions

• Title tags around 50 to 60 characters, unique per page, in natural language that includes the page’s core topic (see Influencing Title Links in Google Search; Google sets no hard limit, so the range is an industry rule of thumb).
• Meta descriptions around 155 characters, written like ad copy rather than a keyword list. Then see the previous section about expectations.

Indexing controls

• Canonical URLs tell search engines which version of a page is the real one and prevent duplicate-content problems (see What is URL Canonicalization). Generate them automatically from the page path so nobody has to maintain them by hand.
• A noindex tag keeps a page out of search results even if it still appears in the XML sitemap (see Block Search Indexing with noindex). Major engines follow the on-page directive, so there’s no need to build sitemap-filtering logic around it.
• Keep an XML sitemap that lists every page and PDF, with last-modified dates, and use robots.txt to keep crawlers out of places they don’t belong (see Build and Submit a Sitemap and Robots.txt Introduction and Guide).
• Block dev, QA, and staging environments from indexing entirely. Few things look worse than a half-finished staging page outranking production.

Multilingual sites

• Generate hreflang alternate links for each language plus an x-default (see Localized Versions of your Pages). This is the technical half of the second-language point above: translated pages that the engines can’t connect to their originals only solve half the problem.

Social sharing

• Open Graph and social card tags control the title, description, and image when a page is shared on LinkedIn, Facebook, or in a text message (see The Open Graph protocol). Pull them from the same SEO fields so authors aren’t entering the same text three times.

Speed and Mobile Are Part of the Content

Google uses page speed and stability as ranking signals, measured as Core Web Vitals (see Understanding Core Web Vitals and Google search results). The targets:

• Largest Contentful Paint (LCP): 2.5 seconds or less
• Interaction to Next Paint (INP): 200 milliseconds or less
• Cumulative Layout Shift (CLS): under 0.1

These are mostly engineering’s job (server-side rendering, caching, optimized images, deferred scripts), but they decide how well an author’s page performs, so authors should know they exist.

Google also indexes the mobile version of a page as the primary version (see Mobile-first Indexing Best Practices). Content, structure, and functionality need full parity between mobile and desktop. Anything that is “desktop only” is, as far as the index is concerned, not there.

SEO Gets You Found, GEO Decides Whether You Get Quoted

AI systems discover content the same way search engines do: they follow links, read sitemaps, and crawl pages. The difference shows up after discovery. A search engine ranks a page; an AI system reads it closely enough to decide whether it is credible enough to quote in an answer. That deeper read is what separates GEO from SEO.

Some GEO requirements are pass/fail, though, rather than better or worse:

• Content has to be in the raw HTML. Most AI crawlers (Google is the notable exception) don’t execute JavaScript. Body content injected client-side after page load is invisible to them, and no amount of good writing fixes that. Being able to see it in your browser proves nothing; check view-source.
• Crawlers have to get through the front door. A CDN rule or firewall can quietly block GPTBot, ClaudeBot, or PerplexityBot, and the only evidence is in the server logs (see Overview of OpenAI Crawlers for the user agents involved). Someone on the ops side should review those logs on a regular schedule.

Either one will sink excellent content just as thoroughly as a scanned PDF.

The Markup Nobody Reads

The original plan for that project included JSON-LD structured data and an llms.txt file, because that is what most of the GEO advice circulating at the time recommended. A closer look found the evidence behind it was anecdotal at best. Ahrefs found that 97% of llms.txt Files Never Get Read, and Google has said plainly that structured data won’t make a site rank better. Both formats make more sense on an intranet, where an AI system is told to look there first to save on tokens. On a public site, they are metadata that nobody reads.

Both were dropped from scope, which freed build time for features people actually use and spared content authors from maintaining fields with no verifiable value.

Anyone who remembers stuffing the meta keywords tag in 1998 (back when Yahoo! still reigned supreme, new listings were reviewed by a human, and a tiny startup would give you a “I’m Feeling Lucky” option) will recognize the pattern. GEO advice turns over in days and weeks rather than the months and years SEO took, and much of it comes from tooling vendors with a commercial interest in urgency. The safe filter is boring: stick to what controlled studies or confirmed technical requirements support, and treat the rest as marketing until proven otherwise.

Authority Is a Writing Problem

Once the plumbing is in place, GEO is about how the content is written. AI systems quote content that reads as authoritative on a topic, and authority comes from formatting and wording.

Start with natural language. Keyword stuffing has been a spam signal for years (see Spam Policies for Google Web Search), and AI systems weigh it even more heavily against you. Named authors, cited sources, and stated policies all signal that the page knows what it is talking about, and internal links with descriptive anchor text help both people and machines see how your pages relate.

Outside credibility still counts too: quality backlinks from relevant, reputable sites and mentions of the company across the web. They have to be earned, though, and can’t be configured. And the headings, short sections, and scannable lists that help a screen reader user also help an AI system pull out a clean, quotable answer.

None of that conflicts with brand voice. Clear, plain language written for a real audience is exactly what readers, search engines, and AI systems all reward. The topics come from your SEO strategy; GEO is whether the page about each topic reads like the definitive answer or like filler with the right keywords in it.

Make the Right Way the Default Way

Guidelines that depend on everyone remembering them are held together with bubblegum and baling wire. The better approach is to bake them into the tools:

• Let the CMS enforce the basics: character counters on titles and descriptions, required alt text, and blocked publishing when required SEO fields are empty. Problems get caught before they go live, at no extra effort for authors.
• Run accessibility linting in the CI pipeline and set it to block failing builds, so problems get caught in code before anyone files a ticket. Pair it with manual checks, because automated tools only catch part of what WCAG covers.
• Scan the live site continuously. Broken links, new accessibility issues, and performance regressions creep in after launch, and a continuous QA scanner finds them before your customers do.
• Treat the Search Console Queries report as a to-do list. It shows searches where you appear but don’t rank well yet, which is the most direct list of content opportunities you will get for free.
• Tag each major release in your analytics, so when rankings or traffic shift you can tie the change to a launch instead of guessing.

Help the Humans First

Build for the person using a screen reader and write like you know the subject. Do that, and most of what gets sold as SEO and GEO work is already done. The work costs something up front, but it only has to be done once.