Where we are, and how we got here

Sometime between the last winter holiday and the first warm week of May, the rules of the game changed. Not loudly. Not with a press release that anyone read all the way through. The shift happened in the small print of platform documentation, in deprecation notices, in the quiet retirement of features that used to be a competitive edge.

If you stopped reading SEO guidance in 2024 and came back today, you would walk into a room where half the furniture has been moved and nobody bothered to leave a note. FAQ rich results, the workhorse of a thousand publishing checklists, stopped appearing in Google Search on May 7, 2026. HowTo rich results were quietly written out of the script. The whole conversation about AI-specific optimization, the one that had marketers chasing imaginary file formats and pretending to know what an “AI sitemap” was, has been settled by the simplest possible answer: there isn’t one. Google says the same SEO best practices apply to AI Overviews and AI Mode. If your page is indexed and eligible for a snippet, it is eligible for the AI surfaces too. That’s the whole spec.

This guide is the journey from that old map to the new one. We will walk through what changed, what stayed, what to keep doing, and what to stop pretending matters. The destination is a single, calm idea: in 2026, SEO and AEO are one operating system, and the work is mostly editorial honesty in a technical container.

The lay of the land

Before we set off, here is the map. Every row is a place where the old playbook and the new reality disagree.

One more thing before we leave the trailhead: this rulebook is CMS-agnostic. WordPress, Drupal, HubSpot, headless, Next.js, Astro, custom — it doesn’t matter. What matters is that the rendered HTML coming out the other side has a correct <title>, a meta description, a canonical, valid structured data, real crawlable <a href> links, and any lazy-loaded content that you actually want discovered. Google’s guidance on crawlable links and lazy loading is unforgiving on this point, and pretending your framework is a special case is how careers in organic traffic end.

The first leg: writing for humans who happen to be searching

Intent, semantic coverage, and the funeral for “LSI keywords”

Let’s bury something on the way out. “LSI keywords” was never a real Google concept, and in 2026 it is finally, fully obsolete. What replaced it is more demanding and more humane: write the way different people would actually search. A beginner uses one vocabulary. An expert uses another. Google’s language systems can already bridge most of those query variations on their own. Your job is not to force every synonym into the prose. Your job is to cover the territory of the question.

The shift is from keyword density to intent coverage. Pick one primary intent for the article. Write it down as a single sentence: “This page should satisfy users who want to ___.” Then list the supporting intents — three to eight related questions a real reader would ask once their first one is answered. Then list the entities that disambiguate the topic. The names, products, places, concepts that have to appear or the article doesn’t make sense.

Now write the article. Each major sub-intent gets its own heading. Each heading gets a real answer. Define what needs defining. Compare what needs comparing. Show examples where examples help. Then stop. Google has said it directly: there is no magical content length, and writing naturally beats stuffing every time.

Titles, headings, and the metadata that still matters

The <title> element is having a strange second life. Google can now build a title link from several sources — the <title> tag, the <h1>, on-page text, anchor text from inbound links, and og:title. That sounds like the title tag matters less. It actually means it matters more, because it is the one signal you fully control. Boilerplate titles get rewritten. Repetitive titles get rewritten. Vague titles get rewritten. A clear, unique, descriptive title is the one that survives.

There is no hard character limit, but devices truncate, and humans glance. The house rule is one strong phrase, usually 45 to 65 characters in en-US, with the topic at the front and the brand only if the brand earns its keep.

The meta description has the same shape of advice. No fixed length. No magic number. Google may use it, or may build a snippet from the page itself. Write one or two real sentences — usually 120 to 160 characters — that tell the reader why clicking is worth their time. Resist length theater.

Headings are even simpler than the SEO industry made them sound for a decade. Use one clear <h1> that matches the article’s promise. Use <h2>s to mark the real sections. Use <h3>s when an <h2> needs a child. There is no ranking lever hidden in heading order. There is, however, a usability lever, and a screen-reader lever, and an answer-extraction lever, all rolled into the same act of “structure the page so a human can scan it.”

Editorial quality, E-E-A-T, and the question that decides everything

Of all the acronyms search has ever spawned, E-E-A-T is the one that finally grew up. Google has said the quiet part loudly: trust matters most. Experience, expertise, and authoritativeness are inputs. Trust is the output. And the way Google evaluates trust is by asking three questions about every page it sees: Who made this, How was it made, and Why does it exist?

If you cannot answer those three questions on behalf of your own article, no amount of schema will save it. So make authorship legible. Add a byline where a reader would expect one. Link the byline to a real author page with credentials and recent work. Use Person or Organization in the structured data with a url or sameAs so the search engine can connect the dots between this article and the human or institution behind it.

On AI-generated content, Google is permissive but not naive. Generative AI is fine. Scaled, careless production designed to flood the index is not, and Google’s spam policies are explicit about it. Where AI materially helped, document the process internally and disclose it externally when that context would actually matter to a reader. And do not touch dateModified unless you genuinely modified something. Faking freshness is one of the older bad ideas, and Google has explicitly warned against it.

AEO in 2026, or: how to be quoted by the machines

The most freeing news in this whole rulebook is that AEO for Google is not a separate discipline. Same SEO best practices. No special schema. No machine-readable file. Pages need to be indexed and snippet-eligible. That’s it.

What that leaves us with is editorial discipline:

• Put the direct answer early. Not in paragraph six.
• Use question-led <h2>s and short summary paragraphs underneath them.
• Then go deep — evidence, examples, links, nuance.
• Use comparison tables for compare-intent queries.
• Use ordered steps for task-intent queries.
• Keep the important stuff in visible text, not buried in interactive UI.
• Make the structured data match what the reader actually sees on the page.

If you want to limit what Google extracts, the controls already exist: nosnippet, data-nosnippet, max-snippet, and noindex. Use them where you mean to.

Bing is the surprise of the year. Its AI Performance public preview tells you, with actual data, how often your URLs are cited in Copilot answers and AI summaries. For the first time, AEO is measurable rather than theological. Treat it that way.

For featured snippets, People Also Ask, and knowledge panels, Google publishes no standalone optimization spec. The defensible approach is the same one that works everywhere else in this rulebook: write extractable answers, name the entities, keep author and publisher identity consistent, mark up Organization or Profile or Article where appropriate, and back claims with sources.

The second leg: the technical layer underneath the prose

URLs, canonicals, hreflang, and the pagination question

Google’s URL guidance reads like advice from a librarian: keep them readable, descriptive, built for humans, with hyphens instead of underscores and as few useless parameters as possible. Session IDs and query-string sprawl create indexing problems. The fix is a structure you could read aloud without embarrassment.

For canonicalization, use rel="canonical" in HTML or HTTP headers. Prefer absolute URLs. Do not try to use robots.txt, the URL removal tool, or noindex as a canonical substitute — they each do something else, and using them wrong creates the kind of bug that takes a quarter to diagnose. Internal links should point at the canonical URL, not at variants. If you use hreflang, the canonical for each localized page should be in the same language.

Pagination is where teams still trip. Each paginated page should have its own URL and its own self-canonical. Do not canonicalize the entire sequence to page 1. Link the pages together with real <a href> links, because Google’s crawlers do not click “Load more” buttons and do not trigger user-action JavaScript. If you ship infinite scroll, there must be paginated URLs underneath it. Otherwise the second screen of content does not exist as far as Search is concerned.

<link rel="canonical" href="https://example.com/en-us/article-slug/" />
<link rel="alternate" hreflang="en-us" href="https://example.com/en-us/article-slug/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/article-slug/" />
<link rel="alternate" hreflang="de-de" href="https://example.com/de-de/artikel-slug/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/article-slug/" />

Structured data, with most of the noise removed

Article schema in 2026 has become almost suspiciously simple. There are no required Article properties. There are recommended ones. Use Article, NewsArticle, or BlogPosting as the type. Include author, datePublished, dateModified, headline, and image. For images, provide multiple high-resolution variants in 16:9, 4:3, and 1:1. For multi-part articles, canonicalize each page or the view-all page — never page 1.

A standard Article in JSON-LD looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Definitive 2026 Article Creation Checklist",
  "description": "A rulebook for creating search-ready and answer-ready editorial content in 2026.",
  "image": [
    "https://example.com/images/article-1x1.jpg",
    "https://example.com/images/article-4x3.jpg",
    "https://example.com/images/article-16x9.jpg"
  ],
  "datePublished": "2026-05-09T09:00:00-04:00",
  "dateModified": "2026-05-09T09:00:00-04:00",
  "author": [
    {
      "@type": "Person",
      "name": "Jane Editor",
      "url": "https://example.com/authors/jane-editor"
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "Example Media",
    "url": "https://example.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": "https://example.com/en-us/definitive-2026-article-creation-checklist/"
}
</script>

A NewsArticle swaps the type and adds the kind of fields a newsroom cares about:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Search platforms update article guidance for 2026",
  "image": [
    "https://example.com/images/news-1x1.jpg",
    "https://example.com/images/news-4x3.jpg",
    "https://example.com/images/news-16x9.jpg"
  ],
  "datePublished": "2026-05-09T09:00:00-04:00",
  "dateModified": "2026-05-09T11:15:00-04:00",
  "author": [
    {
      "@type": "Person",
      "name": "Reporter Name",
      "url": "https://example.com/authors/reporter-name"
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "Example News",
    "url": "https://example.com"
  },
  "mainEntityOfPage": "https://example.com/news/search-platforms-update-article-guidance-2026/"
}
</script>

FAQPage still validates, and you can still ship it, but understand what you are buying. Not Google rich results — those are gone. You ship it because some other consumer in your stack reads it.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do FAQ rich results still appear in Google Search?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. As of May 2026, Google says FAQ rich results are no longer appearing in Search."
      }
    }
  ]
}
</script>

HowTo is in the same boat. Same caveat. Use it for semantic reasons or for non-Google consumers, not for a Google visibility bump that no longer exists.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "How to prepare an article for publication",
  "step": [
    {
      "@type": "HowToStep",
      "name": "Validate metadata",
      "text": "Check title, meta description, canonical URL, and structured data."
    },
    {
      "@type": "HowToStep",
      "name": "Test rendering",
      "text": "Verify that key content is visible in rendered HTML and that internal links are crawlable."
    }
  ]
}
</script>

Speakable is the long-tail option. Eligible English news publishers, short audio-friendly summaries of roughly 20–30 seconds per speakable section, targeted at U.S. Google Home devices. Most teams will skip it. The few it fits, it fits well.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Search guidance update",
  "url": "https://example.com/news/search-guidance-update/",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".headline", ".summary"]
  }
}
</script>

Open Graph and X cards: the distribution layer

Social metadata is not search metadata, and treating them as the same thing is how teams end up with great-looking previews and invisible articles, or vice versa. Google does, however, look at og:image as one input when picking a preferred image — so the social preview is also doing a small favor for Search. Make the image relevant, representative of the page, not a generic logo, not buried under text, and high resolution.

<meta property="og:type" content="article" />
<meta property="og:title" content="Definitive 2026 Article Creation Checklist" />
<meta property="og:description" content="A rulebook for creating search-ready and answer-ready editorial content in 2026." />
<meta property="og:url" content="https://example.com/en-us/definitive-2026-article-creation-checklist/" />
<meta property="og:image" content="https://example.com/images/social-cover-1200x630.jpg" />
<meta property="og:locale" content="en_US" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Definitive 2026 Article Creation Checklist" />
<meta name="twitter:description" content="A rulebook for creating search-ready and answer-ready editorial content in 2026." />
<meta name="twitter:image" content="https://example.com/images/social-cover-1200x630.jpg" />

Images: the most underrated content type on your site

Images are where teams either quietly win or quietly lose. Google’s image guidance is concrete enough to read like a contract: high-quality images, descriptive filenames, relevant surrounding text, useful alt text, no keyword stuffing in alt text, and multiple high-resolution variants in 16:9, 4:3, and 1:1 for article schema.

The delivery side is just as concrete. Use srcset and sizes for responsive selection. Use <picture> when art direction or format-switching matters. Always set width and height so the browser reserves layout space and you don’t ship a CLS bug. Prefer AVIF or WebP for photos. Keep SVG for logos and illustrations that need to scale crisply.

Lazy loading is fine, with one rule that has become non-negotiable in 2026: never lazy-load the LCP image. If a hero image is likely to be your Largest Contentful Paint element, give it fetchpriority="high" and let it load eagerly. The hero image is the part of the page Google’s measurements care about most.

<picture>
  <source
    type="image/avif"
    srcset="
      /images/article-cover-480.avif 480w,
      /images/article-cover-800.avif 800w,
      /images/article-cover-1200.avif 1200w"
    sizes="(max-width: 768px) 100vw, 800px" />
  <source
    type="image/webp"
    srcset="
      /images/article-cover-480.webp 480w,
      /images/article-cover-800.webp 800w,
      /images/article-cover-1200.webp 1200w"
    sizes="(max-width: 768px) 100vw, 800px" />
  <img
    src="/images/article-cover-800.jpg"
    srcset="
      /images/article-cover-480.jpg 480w,
      /images/article-cover-800.jpg 800w,
      /images/article-cover-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 800px"
    width="1200"
    height="675"
    alt="Editorial workflow board showing drafting, optimization, QA, and publishing steps"
    loading="eager"
    fetchpriority="high" />
</picture>

Links: the polite ones, the suspicious ones, and the ones that open new tabs

Google says links are how it finds most new pages. They are also how it understands relevance. Crawlable links are real <a> elements with an href, and the anchor text should describe what is on the other side. Generic anchors like “click here” leak meaning. Stuffed anchors look manipulative. Descriptive, natural anchors do the job.

For outbound link qualification, Google has three values that mean something to it: sponsored for ads or paid placements, ugc for user-generated content, and nofollow for everything else you do not want to vouch for.

The target="_blank" question has nothing to do with SEO and everything to do with security and analytics. rel="noopener" stops the new page from accessing window.opener — that is the security default. rel="noreferrer" additionally suppresses the Referer header, which has analytics consequences for the site you link to. Google does not treat either as an SEO signal. Use them for the reasons they exist.

<a
  href="https://external-site.example/resource"
  target="_blank"
  rel="noopener noreferrer">
  Read the source document
</a>

Internal linking, finally, should be deliberate. Every new article should link to a few older relevant pieces. At least one hub or category page should link back. Anchors should describe destinations. Internal links should point to canonical URLs, never to parameterized variants that you spent the canonical tag trying to consolidate. Internal linking is the cheapest, most underused lever in publishing. Use it.

Mobile-first indexing, Core Web Vitals, and the accessibility floor

Mobile-first indexing means parity. The mobile page must contain the same primary content, the same images, the same alt text, and the same structured data as desktop. If you serve a stripped-down mobile experience, you are stripping down the version Google indexes.

The Core Web Vitals targets in 2026 are LCP within 2.5 seconds, INP under 200 ms, and CLS under 0.1. Hit them. Reserve layout space for media. Don’t let a third-party embed slide content around half a second after paint. Don’t lazy-load the hero. The math is unsentimental.

Accessibility, in this rulebook, means WCAG 2.2 AA as the floor. Meaningful heading structure. Real alt text. Sufficient color contrast. Visible focus states. Keyboard usability. Labeled form fields. Link text that makes sense out of context. Touch targets that fingers can actually hit. None of this is exotic. All of it is the price of admission.

The third leg: the workflow that holds it all together

A rulebook that lives in someone’s head dies when that person leaves. So the workflow has to be a real thing — written down, repeatable, owned. Google’s structured-data guidance suggests build, validate, deploy a few pages, inspect, and submit sitemaps. Search Console gives us URL inspection, indexing reports, sitemap submission, performance data, and Core Web Vitals. Bing adds URL inspection, search performance, recommendations, IndexNow, and AI Performance. The shape of the loop is:

1. Brief the article and map the intent.
2. Draft with evidence and entities.
3. Add metadata and on-page structure.
4. Add schema and social tags.
5. Run performance and accessibility QA.
6. Validate render and indexing.
7. Publish and submit via sitemap or IndexNow.
8. Monitor in Search Console and Bing.
9. Refresh based on what the data says.

The analytics events worth firing

None of these are required by any search engine. They are the events that, in our experience, tell you whether an article is doing the work you wrote it to do.

Google has confirmed that AI-surface traffic still rolls into the Web performance data inside Search Console, and recommends tracking conversions and time on site in your analytics tool. Bing’s AI Performance fills in the citation side. Together they are the closest thing to a complete picture we have ever had.

What to test before and after publish

Before publish: validate structured data where the feature still exists, check rendered HTML in URL Inspection or equivalent, confirm indexability, canonical, and snippet controls, confirm the hero image is discoverable and not lazy-loaded, confirm internal links are real <a href> links, and confirm paginated articles have persistent URLs.

After publish: request indexing for priority URLs, watch the Page Indexing report for exclusions and duplicates, confirm the sitemap, review Performance by URL and query, watch CWV field data for regressions, and check Bing — URL inspection, recommendations, search performance, AI Performance, and IndexNow health if you use it. Publish is the midpoint, not the finish line.

The priority matrix: what to fight for, what to consider, what to skip

The templates, for the people who will copy them at 4pm on a Friday

Article creation checklist

ARTICLE TITLE:
PRIMARY INTENT:
PRIMARY QUERY:
SUPPORTING QUERIES:
CORE ENTITIES:
TARGET AUDIENCE:
ARTICLE TYPE: [Article / NewsArticle / BlogPosting]
CANONICAL URL:
LOCALE: [e.g. en-US]
BRIEF
[ ] One-sentence intent statement written
[ ] Primary query and supporting queries mapped
[ ] Core entities listed
[ ] Searcher stage identified
[ ] Business goal and CTA defined
CONTENT
[ ] H1 written and aligned to primary intent
[ ] Intro answers the core question quickly
[ ] Each H2 maps to a distinct user need
[ ] Definitions, examples, comparisons, or steps included where relevant
[ ] Claims supported with trustworthy sources
[ ] Original analysis, evidence, or synthesis added
[ ] Final copy is readable, well organized, and non-repetitive
[ ] Primary CTA included
[ ] Secondary internal-link CTA included
TRUST
[ ] Byline present where expected
[ ] Author page linked
[ ] Dates checked
[ ] "Who, How, Why" clear
[ ] AI use reviewed for possible disclosure
ON-PAGE SEO
[ ] Unique <title> written
[ ] Unique meta description written
[ ] Title, H1, and intro are aligned
[ ] Key entities and supporting terms included naturally
[ ] Meta keywords omitted
TECHNICAL
[ ] Canonical tag present
[ ] URL is descriptive and stable
[ ] Self-canonical confirmed
[ ] Hreflang added if localized
[ ] Pagination handled correctly if applicable
STRUCTURED DATA
[ ] Article or NewsArticle JSON-LD present
[ ] Author URLs included
[ ] datePublished and dateModified valid
[ ] Image array includes 1:1, 4:3, 16:9 where available
[ ] Schema matches visible content
SOCIAL
[ ] og:title added
[ ] og:description added
[ ] og:url added
[ ] og:image added
[ ] twitter:card and matching social tags added if needed
IMAGES
[ ] Descriptive filenames used
[ ] Alt text written in context
[ ] Width and height declared
[ ] Responsive srcset or picture implemented
[ ] Compression applied
[ ] LCP image is not lazy-loaded
LINKS
[ ] Internal links added to relevant older pages
[ ] Hub or category page links back if needed
[ ] External links reviewed
[ ] If target="_blank" is used, rel="noopener" added
[ ] Sponsored, UGC, or nofollow applied only when appropriate
QUALITY
[ ] Mobile rendering checked
[ ] Accessibility spot-check completed
[ ] Search preview checked
[ ] Rendering checked in a crawler-like view
[ ] Publish decision approved

Pre-publish QA checklist

PRE-PUBLISH QA
INDEXING
[ ] URL returns 200
[ ] Canonical points to preferred URL
[ ] Robots directives allow indexing
[ ] Page is included in sitemap or queued for IndexNow if used
RENDERING
[ ] Main content is visible in rendered HTML
[ ] Important links are <a href> links
[ ] Lazy-loaded content appears without user-only actions
[ ] Structured data is present after render
SEARCH APPEARANCE
[ ] <title> is unique and accurate
[ ] Meta description is unique and useful
[ ] H1 is clear
[ ] Main image is representative
[ ] og:image and social tags resolved correctly
SCHEMA
[ ] JSON-LD validates
[ ] Article type is correct
[ ] Author, dates, headline, image present
[ ] Schema content matches visible page content
PERFORMANCE
[ ] LCP image is eagerly discoverable
[ ] Width and height set on media
[ ] No major CLS issues in test
[ ] JS and image weight acceptable
[ ] Mobile PageSpeed review completed
ACCESSIBILITY
[ ] Heading structure makes sense
[ ] Alt text present and useful
[ ] Link text is descriptive
[ ] Focus visibility works
[ ] Color contrast and touch target basics checked
LINKS
[ ] Internal links point to canonicals
[ ] No broken links
[ ] External target behavior reviewed
[ ] rel values reviewed
POST-PUBLISH
[ ] URL inspected
[ ] Indexing requested for priority pages
[ ] Performance report annotation added
[ ] Monitoring owner assigned
[ ] Refresh review date scheduled

What we don’t know, and why we said so

Two parts of this rulebook are honest extrapolations rather than direct quotations of platform docs. First, there is no standalone official optimization spec for People Also Ask or knowledge panels. The recommendations here are inferred from current guidance on snippets, AI features, structured data, authorship, and entity clarity. Second, X’s documentation surface for card markup is fragmented enough that the example syntax above reflects standard production usage rather than a single canonical reference.

Neither gap changes the journey. The destination has been the same since we set out: clear answers, visible text, trustworthy authorship, valid article schema, stable technical signals, and post-publication monitoring that you actually look at. Everything else is a footnote.