Technical SEO Checklist for 2026: What Actually Moves Rankings Now | Blog

# Technical SEO Checklist for 2026: What Actually Moves Rankings Now

TL;DR: In 2026, the technical SEO items that actually move rankings are INP-driven responsiveness, crawl-capacity efficiency (TTFB + HTTP caching), keeping structured data limited to schema types Google still renders as rich results, and making sure crawlability/indexability hold up for both classical Search and AI Overviews — FAQ schema and llms.txt are not on that list.

Most "technical SEO checklist" posts still lead with advice written for a 2020 index: submit a sitemap, add FAQ schema, minify your CSS. Some of that is still baseline hygiene. But three things changed the actual mechanics of crawling, rendering, and rich-result eligibility in the last two years, and a checklist that doesn't account for them will have you spending effort on things Google has already deprecated.

This is a working audit checklist, not a strategy essay. Each section names what changed, when, and what to actually do about it — with sources.

1. Core Web Vitals: INP is the metric that penalizes you now

Interaction to Next Paint (INP) replaced First Input Delay as the official Core Web Vitals responsiveness metric in March 2024, and by 2026 it's the one most sites are actually failing. The thresholds, per Google's own web.dev documentation, are:

INP (75th percentile, field data)	Rating
≤ 200ms	Good
200–500ms	Needs improvement
> 500ms	Poor

Unlike FID, INP measures the full event — input delay, processing time, and presentation delay — across every interaction on the page, not just the first one. Heavy client-side JS (large component trees, uncoalesced re-renders, third-party scripts firing on click/input) is what usually blows the budget, not initial load weight.

Audit it in the field, not just in the lab — lab tools (Lighthouse) can't measure INP the same way CrUX does, because it needs real user interactions:

// Log real INP in production using the official web-vitals library
import { onINP } from 'web-vitals';

onINP((metric) => {
  // send to your analytics endpoint — segment by device type
  navigator.sendBeacon('/api/v1/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
    id: metric.id,
  }));
});

Check the field data in Search Console's Core Web Vitals report and in CrUX (chromeuxreport.googleapis.com) rather than trusting a single Lighthouse run — Lighthouse simulates a synthetic interaction and will understate real-world INP on interaction-heavy pages.

2. Crawl budget is a speed and caching problem, not a sitemap problem

Google updated its "Optimize your crawl budget" documentation on July 22, 2026, clarifying two things that change how you should prioritize server-side work: every site now starts from the same conservative default crawl-capacity limit (which Google raises automatically as demand grows and your server stays fast and healthy), and that capacity is shared across all of Google's crawlers — including AI-training crawlers — not allocated separately to Googlebot.

Practical consequence: a slow or flaky server doesn't just hurt user experience, it caps how much of your site gets crawled and re-crawled, because Googlebot throttles itself to avoid overloading a struggling origin. The two levers that matter most:

Time to First Byte. Google's own guidance points at keeping TTFB well under 200ms for pages you want crawled aggressively.
HTTP caching (conditional GETs). Returning real 304 Not Modified responses for unchanged resources means Googlebot spends less crawl capacity re-fetching content that hasn't changed, leaving more budget for new/updated pages.

// Express: honor conditional GET requests so unchanged pages return 304
app.get('/blog/:slug', async (req, res) => {
  const article = await getArticle(req.params.slug);
  const etag = `"${article.updatedAt.getTime()}"`;

  res.set('ETag', etag);
  res.set('Last-Modified', article.updatedAt.toUTCString());

  if (req.headers['if-none-match'] === etag) {
    return res.status(304).end();
  }

  res.render('article', { article });
});

For large sites (tens of thousands of URLs), this matters more than any amount of internal-linking cleverness — it's the difference between Googlebot re-crawling your changed pages within hours versus days.

3. Structured data: stop maintaining FAQ schema

Google added a deprecation notice to its FAQ structured data documentation, and as of May 7, 2026, FAQ rich results no longer appear in Google Search results at all (outside a narrow carve-out for well-known government/health sites). The FAQ appearance filter and the FAQ rich result report in Search Console are being removed, with Search Console API support following in August 2026. HowTo rich results were deprecated earlier still, in September 2023.

This doesn't mean the markup breaks anything if it's still on your pages — unused structured data doesn't cause errors — but it does mean auditing your JSON-LD against a 2026 list of schema types that still earn a visual treatment in Search is worth doing before you invest more engineering time in a new type. Schema types still producing rich results in 2026 include Product/Review/AggregateRating, Article, Recipe, VideoObject, Organization, LocalBusiness, and BreadcrumbList.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Technical SEO Checklist for 2026",
  "datePublished": "2026-08-25",
  "dateModified": "2026-08-25",
  "author": { "@type": "Organization", "name": "Wise Hustlers" },
  "publisher": {
    "@type": "Organization",
    "name": "Wise Hustlers",
    "logo": { "@type": "ImageObject", "url": "https://wise-hustlers.com/logo.png" }
  }
}

Use JSON-LD in the document <head>, not microdata — Google still parses both, but AI answer engines are tuned to pick up JSON-LD blocks more reliably.

4. IndexNow: useful, but not for Google

IndexNow is the open protocol (originally from Microsoft and Yandex) that lets you push a URL directly to a search engine the moment it changes, instead of waiting for the next crawl. As of 2026, Bing, Yandex, Naver, Seznam, and Yep all participate — a single ping reaches all of them. Google does not support IndexNow. It relies on its own crawl infrastructure and Search Console's URL Inspection/indexing tools instead.

The reason it's still worth wiring up: Bing's index is a direct data source for Copilot and (via licensing) other AI answer engines, so instant Bing indexing has become a proxy for AI-search visibility even on sites that get most of their traffic from Google.

curl -X POST https://api.indexnow.org/indexnow \
  -H "Content-Type: application/json" \
  -d '{
    "host": "wise-hustlers.com",
    "key": "your-indexnow-key",
    "keyLocation": "https://wise-hustlers.com/your-indexnow-key.txt",
    "urlList": ["https://wise-hustlers.com/blog/new-post"]
  }'

Treat it as one layer of a dual strategy: IndexNow for fast Bing/Yandex propagation, XML sitemaps plus Search Console for Google.

5. AI crawlers and llms.txt: don't over-invest yet

Google's own developer documentation is explicit that the same foundational technical SEO — crawlability, indexability, a valid robots.txt, snippet eligibility — is what determines whether a page can be surfaced as a supporting link in AI Overviews or AI Mode. There is no separate technical requirement and no special AI markup needed to be eligible.

llms.txt (a proposed /llms.txt file summarizing a site for LLMs, introduced by Jeremy Howard in September 2024) is worth understanding but not worth prioritizing: as of early 2026, no major AI lab — OpenAI, Google, Anthropic, or Meta — has publicly committed to reading or acting on it in production, and Limy.ai's monitoring of over 500 million AI bot visits across a 90-day window found only 408 that targeted llms.txt at all (Limy.ai); a smaller independent study by OtterlyAI reached the same conclusion, with 84 of 62,100+ AI bot visits hitting /llms.txt (OtterlyAI). What does matter is making sure your robots.txt reflects a deliberate decision about each AI crawler, rather than a default block or default allow:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: *
Disallow: /admin/
Disallow: /api/

Audit which bots are hitting your server (via access logs or a CDN dashboard) before deciding what to allow — blocking indiscriminately can remove you from AI answer surfaces you'd otherwise appear in for free.

6. Rendering and fetch limits still trip up JS-heavy sites

Two constraints from Google's crawling documentation are easy to forget when a site ships more client-side JavaScript every quarter: as of Google's February 2026 documentation update, Googlebot crawling for Search fetches only the first 2MB of a supported file type and the first 64MB of a PDF, with a 15MB default applying more broadly across Google's other crawlers and fetchers (Search Engine Journal) — the limit is measured on uncompressed data, and once it is hit Googlebot stops and indexes only what it already downloaded. Crawling has also used the mobile Googlebot user agent for all sites since July 5, 2024, under full mobile-first indexing. If critical content or links only render after 2MB of JS has executed, or only appear in a desktop layout, they may never be seen by the crawler that indexes your site.

A practical audit order

1. Confirm robots.txt and canonical tags aren't accidentally blocking or self-conflicting.

2. Pull CrUX/Search Console field data for INP, LCP, and CLS — fix INP first, it's the one most JS-heavy sites are actually failing.

3. Check TTFB and confirm conditional GET / 304 responses work on your CDN and origin.

4. Audit JSON-LD against the current rich-result-eligible schema list; drop time spent on FAQ/HowTo markup.

5. Wire up IndexNow for Bing/Yandex if content changes frequently; keep sitemaps current for Google.

6. Review robots.txt AI crawler directives against server logs, deliberately, not by default.

None of this requires much beyond in-house engineering time to execute — it's mostly a matter of prioritizing the right five items over the twenty low-impact ones. Teams without spare technical bandwidth to run this as a recurring audit sometimes fold it into a broader site build or replatform engagement rather than treating it as a one-off.

FAQ

Do Core Web Vitals still matter for rankings in 2026?

Yes, but as one signal among many, and INP — not LCP — is the one most sites now fail. Google's own thresholds (≤200ms good, >500ms poor) are measured from real-user field data, not lab tests, so audit via CrUX/Search Console rather than a single Lighthouse score.

Should I add an llms.txt file to my site?

It's low-cost to add but currently low-impact: no major AI lab has confirmed it reads llms.txt in production, and observed adoption by AI crawlers is near zero as of early 2026. Prioritize standard crawlability and structured data first.

Is IndexNow worth implementing if most of my traffic comes from Google?

Yes, as a supplementary channel. Google doesn't consume IndexNow submissions, but Bing does, and Bing's index feeds Copilot and other AI answer engines — so it can improve AI-search visibility even when it doesn't move Google rankings directly.

Do I still need FAQ schema on my pages?

No new value from adding it — FAQ rich results stopped appearing in Google Search as of May 7, 2026. Existing markup won't cause errors if left in place, but it's no longer worth engineering time.