Recap on Technical SEO for News Publishers

The central thesis of the talk is that Technical SEO is no longer a separate “plumbing” function but a core driver of ranking performance. Barry argues it has moved beyond just “crawling and indexing” to include all technical elements that have a “direct impact on how high a website is shown.”

His analysis focuses on the most common and costly failures for publishers:

The Crawl Budget Fallacy: “Stop Wasting Google’s Time”

Barry frames crawl optimization not as gaining budget but as not wasting it.

• Server Response Time: This is identified as the “biggest factor” impacting crawl rate. He provides a clear metric: server response time should be under 600 ms, as Google flags anything slower as a “critical issue” in the core web vitals reports.
• Wasted URLs: He highlights that publishers “don’t realize the value of a URL anymore.” The two main sources of waste are:
• Internal Redirects: These are pure crawl overhead. All internal links must point to the final 200-status destination.
• Parameters & Canonicals: This is a key failure. He stresses that rel=canonical “doesn’t solve crawl waste” because Google still must crawl the duplicate page to see the tag. The common culprit is internal tracking parameters.
• The Solution: For internal tracking, use a hash (#), which Google ignores, rather than a query parameter (?), which creates a new URL.

The JavaScript “Time-Bomb”: Rendering Delays

This is positioned as the most critical issue for News Publishers.

• The “Devastating” Delay: Barry states that rendering is not real-time but a queue. He directly refutes Google’s “hopelessly optimistic” 2-minute average, stating from experience the delay is “several hours at least.”
• The Impact: For a news site, a “few hours delay is devastating.” By the time Google renders the client-side content, the article is “old news” and loses all value in Top Stories.
• The Non-Negotiable Fix: All critical content—the full article text, headlines, and internal links—must be in the initial HTML response. Relying on client-side JS is not a viable strategy.

Pagination vs. Topic Authority

Barry identifies pagination as the “single most common issue” he finds on news sites.

• The Failed Implementations: “Infinite scroll” and “load more” buttons. Because Google “does not scroll” and “does not click,” it sees only the first page of articles.
• The “Aha-Moment”: This is not just about crawl depth; it’s about topic authority. Google needs to see the full “body of work” to deem a publisher an expert. If Google sees only 10 articles on a topic page, it cannot confer authority.
• The Solution: Implement indexable paginated pages but with a finite limit (e.g., 9 pages). Then, link from the last page to a “database archive”. This ensures all content remains discoverable, keeping every article 3-4 clicks from the homepage.

Strategic & Surgical Nuances

• Structured Data: “Keep it lean.” He argues against building complex, interlinked graphs, warning they can “confuse Google.” He views Schema as a “supplementary mechanism,” not a primary one.
• AEO is Just SEO: Optimizing for LLM training and RAG (Retrieval-Augmented Generation) requires the exact same fundamentals: semantic HTML and all content in the initial HTML response. “It’s f****** SEO.”
• Image Schema (The Takeaway): He provides a highly specific, tactical failure point. For Article schema, publishers should provide exactly three images at 1200px minimum width:
  • 16:9 (Critical for Discover )
  • 4:3
  • 1:1 He warns that providing too many (10-15) images is harmful and has caused clients to lose visibility.
• Core Web Vitals: “Overrated and Underrated.”
  • As a direct signal: Weak, “more of a tie breaker.”
  • As an indirect signal: “Hugely important.” He states CWV is Google’s attempt to give us metrics for a good user experience, which Google does measure directly via click data. The goal is “good enough” (mostly green), not perfection.

INTERVIEW

Christopher Barry – you provided us with an interesting and vivid presentation a couple of minutes ago. I have some questions that I believe people out on the web might find interesting – let’s go?

Barry Sure – shoot!

Christopher You rightly criticize the “div soup” from JS frameworks and the “devastating” indexing delays from client-side rendering. But publishers adopt these frameworks for developer velocity, not for SEO. Given that developer retention is a major C-suite concern, how do you advise clients to win the argument for pure SSR/static HTML when the organizational reality is that they must use these frameworks to attract and retain engineering talent?

Barry There is indeed a good case to be made for getting things done quickly, rather than perfectly. I am a fan of the saying “done is better than perfect.” However, by relying on quick JS hacks and framework shortcuts for making important site changes, there is a huge chance the site incurs more technical debt. This tech debt can eventually cause the site to fail on many different levels, including load speed, usability, and SEO.

Additionally, if a company relies on dev talent that only knows how to code using JS frameworks, arguably that company doesn’t employ any actual web developers – they just employ lazy app developers that think they can build a website by ticking a box in their JS framework of choice. That’s reflective of a deep organisational problem, showing a colossal error in how the company perceives the underlying technology and intrinsic value of their website and how they wish to own and maintain it.

Christopher I like the clarity of that statement. Moving along, here is your second question: You advise keeping structured data “clean and lean” and that complex, interlinked graphs “confuse Google”. This directly contradicts the entity-based SEO narrative, which argues for building a comprehensive site knowledge graph. Are you seeing negative performance from rich entity markup, or just a lack of positive ROI? And does this “lean” advice hold true for RAG, which theoretically should thrive on the explicit entity connections that a complex graph provides?

Barry I see improved visibility and rankings from leaner structured data snippets that only contain the recommended attributes, as defined in Google’s documentation. I believe more intricate entity graphs aren’t being utilised by Google, nor by LLMs. I think the “structured data for everything” movement within SEO is based on the false assumption that search engines (and LLMs) rely heavily on intricate, interlinked structured data, but there is no evidence for this. On the contrary, there is abundant evidence that structured data is only useful to the extent that you provide recommended attributes – and nothing more – to the relevant machine systems.

Now, you may have other motivations to build detailed entity graphs using structured data on your website. But purely for SEO, small structured data snippets are the optimal approach.

Christopher All right! Finally: You equate optimizing for RAG citations with good “classic” technical SEO, meaning semantic HTML and top-ranking pages. However, RAG pipelines increasingly rely on vector similarity search, not just keyword retrieval. Have you seen any evidence that our traditional on-page optimizations have a meaningful impact on a document’s retrieval in a vector-based pipeline, or are we just optimizing for the “synthetic keyword query” and hoping the vector embeddings follow?

Barry There is no ambiguity here, SEO is as much about vector embeddings as LLMs are. Inexperienced SEOs may rely on keywords and topics as shortcuts for content optimisation, but both search engines and LLMs understand content through vector embeddings.

Christopher Thanks for taking the time to answer the questions – be seeing you soon!