TL;DR
Crawlability, indexation, architecture, internal linking, metadata, performance, and duplication control all still matter and still come first. Four things genuinely changed. Rendering is the biggest new risk, because some AI retrieval systems do not execute JavaScript and will see an empty page. AI crawler access is now a deliberate decision per bot rather than a default. Content needs passage-level structure with question headings and answer-first paragraphs, since retrieval works in chunks. URL stability and visible freshness matter more, because moving a URL breaks established citations.
What technical SEO work still matters most?
All of it, honestly. The fundamentals did not get less important when AI answers arrived. They got more leverage, because more systems now depend on being able to fetch and parse your pages.
Here is the short version of what has not changed.
Crawlability and indexation. If a page cannot be crawled, it cannot rank, be summarized, or be cited. Robots rules, noindex tags, and canonical mistakes remain the most common self-inflicted visibility problems I find.
Site architecture. Clear hierarchy, sensible URL paths, and shallow click depth help both search engines and assistants understand which pages matter. A page buried five levels deep signals that you do not think it is important.
Internal linking. Descriptive anchor text is still one of the cheapest wins in SEO, and it now doubles as a relationship map for systems trying to work out how your topics connect.
Page titles, headings, and metadata. Still the fastest summary of what a page is about. Still worth writing carefully rather than templating.
Performance. Core Web Vitals affect user experience and crawl efficiency. Slow pages get crawled less generously, and that has real consequences for large sites.
Duplication control. Near-identical pages split signals and confuse both rankings and retrieval.
None of this is new. It is the base layer that everything in SEO consulting still sits on.
Why has rendering become the biggest technical risk?
This is the change I would put at the top of the list.
Google has rendered JavaScript for years, so many teams stopped worrying about client-side rendering. AI retrieval systems are less forgiving. Several fetch HTML and move on. If your headline, body copy, and answers only exist after a framework hydrates, some systems see a shell.
The test is simple and takes a minute. Fetch your page without JavaScript, or view the raw HTML source, and look for your actual content. If the main copy is missing, that is your finding.
A client on a single-page application framework ranked fine in Google and was invisible in assistant answers. The pages tested clean in Google's tools and empty in a raw fetch. Moving to server-side rendering for the main content changed the outcome within weeks. Nothing about the copy changed.
Practical guidance for marketers: ask your developer whether primary content is server-rendered or client-rendered. That one question surfaces more AI visibility problems than most audits.
How should you handle AI crawlers and bot access?
This is a genuinely new decision, and it deserves a real conversation rather than a default.
Different bots do different jobs. Some crawl to train models. Some fetch pages live to answer a user's question right now. Blocking the first group may protect your content. Blocking the second group removes you from answers you were trying to appear in.
So the choice is not "allow AI bots" or "block AI bots." It is deciding, bot by bot, whether you want training access, retrieval access, or neither.
I usually recommend documenting the decision in a short internal note alongside your robots rules, because the list of user agents changes and the reasoning gets forgotten. Also check your CDN and firewall settings. I have seen sites accidentally block retrieval bots at the edge while their robots file politely allowed them.
Then verify. Server logs tell you which bots actually reached which pages. That is the only reliable way to know whether your intent matches reality.
What has changed about content structure and markup?
Structure moved from a nice-to-have to a retrieval requirement.
Retrieval systems work in passages. They pull a chunk of a page rather than the whole thing. That means the page needs to be built out of clean, self-contained chunks.
What that looks like in practice:
- Question-style headings that match how people actually ask
- A direct answer in the first sentence or two under each heading
- Short paragraphs, because a two-sentence paragraph extracts cleanly and a twelve-line block does not
- Real tables for comparisons instead of paragraphs describing a comparison
- Lists for steps and criteria
- Semantic HTML, so headings are headings and not styled divs
Schema markup matters more too, but for a different reason than it used to. It is less about winning a rich result and more about removing ambiguity from who you are and what you offer. Organization, LocalBusiness, Service, Article, BreadcrumbList, and FAQPage cover most of what a marketing site needs, and each one should mirror what the page visibly says. The details are in schema markup explained for marketers.
Do freshness and stability matter differently now?
Yes, in a way that trips people up.
Assistants often cite pages that read as current. Visible dates, accurate dateModified values in schema, and updated statistics all help. A page that says nothing about when it was written invites doubt.
At the same time, URL stability matters more than ever. When a model or an index has associated a claim with a URL, moving that URL breaks the association. Redirects preserve link equity reasonably well, but they do not instantly repair citations.
The practical rule I follow: update content in place whenever possible, keep URLs stable, and reserve URL changes for genuine structural improvements with a mapped redirect plan. That is the same caution I bring to any platform migration.
What technical work is overrated right now?
A few things get more attention than they deserve.
Chasing perfect performance scores. Getting from a poor score to a good one matters. Getting from 92 to 98 rarely changes business outcomes. Fix the real bottlenecks and move on.
Marking up everything. Schema on every element does not multiply results. Accurate schema on the types that describe your business does.
New llms.txt style files as a primary strategy. They are cheap to add and I do not object to them, but treat them as an experiment rather than a substitute for server-rendered content and clean structure.
Keyword density and word count targets. Neither was ever a real ranking factor, and neither helps a passage get extracted.
What is a practical checklist for a marketer?
You do not need to run a crawl yourself to hold a useful conversation with a developer. Ask these seven questions.
- Is our primary page content present in the raw HTML without JavaScript?
- Which AI bots do we allow, and did we decide that on purpose?
- Are our important pages within three clicks of the homepage?
- Does every priority page answer its main question in the first two sentences under the relevant heading?
- Is our Organization schema accurate, valid, and consistent with the About page?
- Do we have redirect chains, orphan pages, or canonical conflicts?
- Can we see in logs or analytics that AI crawlers are reaching our key pages?
If the answers are unclear, that is a scoping conversation rather than a crisis. Most of these are quick to check and cheap to fix. The order matters more than the effort, which is why I sequence them inside a website audit instead of handing over a flat list.
Technical SEO for AI search FAQ
Does technical SEO still matter for AI search?
Yes, and arguably more. AI systems must fetch and parse a page before they can summarize or cite it. Crawl blocks, rendering problems, and indexation issues remove a page from AI answers the same way they remove it from rankings.
Why does server-side rendering matter for AI search?
Several AI retrieval systems fetch raw HTML without executing JavaScript. If your headline, body copy, and answers only appear after a framework hydrates, those systems can see an effectively empty page even though Google renders it fine.
Should you block AI crawlers in robots.txt?
It depends on the bot. Training crawlers and live retrieval crawlers do different jobs, and blocking the retrieval bots removes you from the AI answers you want to appear in. Decide bot by bot, document the reasoning, and verify in server logs that your rules match reality.
What content structure works best for AI retrieval?
Question-style headings, a direct answer in the first sentence or two beneath each heading, short paragraphs, real tables for comparisons, lists for steps and criteria, and semantic HTML. Retrieval systems pull passages, so each section should stand on its own.
Do Core Web Vitals still matter?
Yes, for user experience and crawl efficiency, but with diminishing returns. Moving from poor to good scores is worth real effort. Chasing the last few points on an already fast site rarely changes business outcomes.