Category: Technical optimization

Hydration and SEO: What I Watch Before Rankings Slip

When I work on a site built with a framework like Next.js, Nuxt, SvelteKit, or a similar JavaScript framework, I pay close attention to hydration. It is the step that turns server-rendered HTML into an interactive page, but it is often explained in a way that does not connect clearly to SEO.

I think hydration is easier to understand when I separate content from behavior. The content may already be visible, but the page may not be fully usable until the browser finishes connecting that content to the JavaScript behind it.

What I mean by hydration

Hydration is the process where JavaScript in the browser takes over the static HTML that was built on the server. The server sends a complete page first, and then the framework attaches the logic that makes buttons, menus, forms, filters, and other interactive pieces actually work.

Here is how I usually explain the sequence. First, the server builds the page and sends fully formed HTML to the browser. I can see the content quickly, but the page is not interactive yet. Then the framework loads, walks through the existing HTML, attaches event listeners, and reconnects the visible markup to the application logic. Once that is done, the page behaves like a normal interactive app.

This is why server-rendered HTML can feel fast at first. It can paint quickly and often helps with first impressions and Largest Contentful Paint (LCP). The tradeoff is that, with traditional hydration, the page may appear ready before it is actually usable.

Hydration adds interactivity, not content

The most important distinction I keep in mind is this: hydration does not add the main content to the page. The text, images, and layout should already be present in the server-rendered HTML. Hydration only adds behavior by wiring that HTML to the JavaScript that responds to clicks, typing, taps, and other user actions.

A hydration timeline shows the gap between content appearing and a page becoming usable: HTML is visible first, but buttons only work after hydration completes.

Put simply, before hydration I can read the page. After hydration, I can use it.

I also avoid confusing hydration with the rendering pattern itself. Server-side rendering (SSR), static site generation (SSG), and client-side rendering (CSR) describe where and when the page is built. Hydration describes what happens after server-rendered or statically generated HTML reaches the browser and needs to become interactive.

From an SEO perspective, that distinction matters. When a page uses SSR or SSG correctly, the core content is already in the initial HTML. Google can discover and index that content from the HTML before depending on a JavaScript render step, which is generally more reliable than sending a mostly empty client-rendered shell.

When I see hydration become an SEO problem

Most of the time, I do not treat hydration itself as an SEO problem. It becomes a problem when hydration breaks, usually because the HTML created on the server does not match what the framework expects to create in the browser.

That kind of mismatch can happen when content depends on browser-only APIs such as localStorage, when a value changes between server and client rendering such as new Date(), when a third-party script or browser extension changes the DOM before hydration finishes, or when invalid HTML causes the browser to rewrite the structure before the framework can attach to it.

Before hydration, a server-rendered page can be read but not used; after hydration, JavaScript adds behavior so elements like the Subscribe button respond.

When the two versions do not line up, the framework may throw away the mismatched section and re-render it in the browser. The exact behavior depends on the framework, but the SEO and performance risks are similar.

For example, if a <time> value is generated with new Date(), the server may output one value while the browser generates another. That mismatch can force a re-render, even though the page appeared to load correctly at first.

I worry about this because it can hurt the page in several ways. A re-render can make the page feel sluggish, which can affect Interaction to Next Paint (INP). It can shift the layout, which can affect Cumulative Layout Shift (CLS). It can also break user actions if event listeners fail to attach properly, leaving buttons, menus, or forms unresponsive.

In severe cases, Google may read the raw server HTML before JavaScript finishes rendering and then index content that visitors never actually see after the page re-renders. That is the scenario I want to avoid most: search engines and users experiencing different versions of the same page.

The fix is usually not an SEO trick. It is a development fix. I want the underlying mismatch removed by using valid HTML, avoiding browser-only logic during server rendering, stabilizing values that change between server and client, and controlling third-party scripts that alter the DOM too early.

When server HTML and browser-rendered content disagree, hydration may discard and rebuild the page, creating layout shifts, broken UI and potential SEO indexing problems.

How I spot hydration problems on a live site

Hydration errors are usually easier to catch in development than on a live site, but I still look for a few practical signals. I start with the browser’s Developer Tools console and check for hydration warnings, JavaScript errors, or framework-specific mismatch messages.

Then I watch the page load carefully. If content flickers, shifts, disappears, reappears, or stays unresponsive for longer than expected, I treat that as a sign worth investigating.

I also use Google Search Console’s URL Inspection tool on important templates to see how Google renders the page. For larger sites, I prefer crawling with JavaScript rendering enabled in tools like Screaming Frog or Sitebulb so I can compare rendered output against raw HTML at scale.

How I think about different hydration approaches

Modern frameworks handle hydration in different ways, and I think of those differences as a balance between performance, interactivity, and how much JavaScript must run in the browser.

Full hydration means the entire page hydrates in one pass. It is straightforward, but it usually ships the most JavaScript and asks the browser to do the most main-thread work. Next.js Pages Router is a common example of this model.

A glowing Google search bar cuts through streams of digital data, capturing the fast-moving world of search, shopping visibility, and SEO innovation.

Partial hydration hydrates only the interactive pieces, often called islands. Static sections remain plain HTML and do not need client-side JavaScript. Astro’s islands architecture is a well-known example of this approach.

Progressive hydration hydrates the page in pieces over time. A framework may hydrate sections as they scroll into view or as browser resources become available. Angular’s incremental hydration follows this general pattern.

React Server Components take a different path by letting some components render entirely on the server and ship no client-side JavaScript for those server-only parts. In those cases, there is nothing for the browser to hydrate for that portion of the page. Next.js App Router uses this model.

Resumability goes further by trying to skip hydration entirely. Instead of re-running components on load, the page resumes from the state the server already produced. Qwik is the main example here, although I still view it as newer and less battle-tested than some of the older patterns.

When I compare these techniques, I look at what hydrates, how much JavaScript ships, and how much work the browser must do. Full hydration touches the entire page and usually ships the most JavaScript. Partial hydration touches only interactive components and ships less. Progressive hydration spreads the work over time. React Server Components reduce hydration for server-only parts. Resumability aims to avoid hydration altogether.

What this means for my SEO work

I do not assume hydration is bad for SEO. In most cases, it is simply part of how modern server-rendered and statically generated sites become interactive.

What I do watch closely is whether the server HTML and the browser-rendered version agree. If they do, hydration is usually a performance and user experience consideration. If they do not, hydration can become a visibility problem, especially when Google indexes a version of the page that users never see.

Newer frameworks reduce some of this risk by shipping less JavaScript and doing less work in the browser, but they do not remove the need for careful implementation. For me, the practical takeaway is simple: make sure the important content is present in the initial HTML, keep server and client output consistent, and test how search engines actually render the page.

Inspired by this post on Search Engine Land.

July 7, 2026
How I Safely Roll Out High-Impact Technical SEO Changes

When I work on technical SEO, I know the right changes can dramatically improve how search engines crawl, understand, and evaluate a website.

I also know that the recommendations with the biggest upside usually carry the biggest implementation risk. URL changes, canonical updates, robots.txt edits, internal linking improvements, and site migrations can all strengthen organic performance, but one mistake can damage crawling, indexing, and search visibility.

That is why I do not treat technical SEO as a simple list of fixes. I treat it as a process: evaluate the impact, weigh the effort and risk, align the right teams, and test everything before and after launch.

From audit to implementation to prioritization

For me, the work is not finished when the SEO audit is delivered.

Prioritization is where the real judgment begins. I look at how severe the issue is, what outcome I expect, how many pages are affected, how much development effort is required, and what could go wrong if the change is implemented poorly.

The recommendations with the greatest potential impact often need buy-in from developers, content teams, product owners, and stakeholders because they require more resources and carry more risk. A clear recommendation, a practical test plan, and early alignment make implementation much easier to move forward.

Understanding the issue and potential outcome

I do not assume every technical SEO issue found in an audit needs immediate action. Before I prioritize a recommendation, I validate it manually and consider the broader context of the site, including priority sections, platform limitations, and business goals.

For example, missing meta descriptions on low-priority pages or title tags that fall outside recommended lengths may appear in an audit because they are easy for tools to measure, not because they will meaningfully affect performance.

Crawling tools and automated reports are valuable because they help me find issues at scale. But they do not always tell me whether an issue matters to the business.

A warning may point to a real problem, an intentional setup, a platform constraint, or something with little to no measurable impact. I need that context before I decide what deserves attention.

Evaluating impact, risk, and effort

Once I validate an issue, I decide how to address it and whether it is worth recommending for implementation.

When I am prioritizing technical SEO recommendations for a development queue, I consider the number of affected pages, the expected outcome, the resources required, and the potential risks.

Updating a few title tags may be low risk. Changing URL structures or modifying robots.txt directives can affect thousands of pages and influence crawling, indexing, and discoverability.

By understanding both the upside and the downside, I can make better decisions, allocate resources more responsibly, and plan changes in a way that reduces risk while still pursuing meaningful gains.

High-impact technical changes that require extra caution

The following technical SEO initiatives can meaningfully affect site performance. I do not avoid them because they are risky. I approach them carefully because their implications, benefits, and failure points need to be understood before implementation.

1. URL updates and changes

I often recommend URL updates when a site needs a clearer folder structure, content consolidation, rebrand support, or stronger information architecture.

For example, a business may move service pages from the root domain into a subfolder so the content is easier to organize and the site is easier to navigate.

URL changes can provide real benefits, but I need to make sure those benefits outweigh the risks and that a proper redirect strategy is ready before anything goes live.

Search engines treat a changed URL as a new URL, so redirects are essential for preserving rankings, traffic, backlinks, and other signals tied to the original page. Missing redirects, bad mappings, redirect chains, outdated internal links, and stale XML sitemaps can all hurt crawling, indexing, and discoverability.

Before I move forward with URL changes, I create a redirect mapping plan. Ideally, I validate and test redirects in a development environment before launch, then check them again after launch and update the XML sitemap.

I also include internal link updates and performance monitoring in the launch plan. Careful planning helps preserve existing SEO equity while supporting the larger goals of the site.

2. Canonical updates

Canonical tags help search engines understand which version of a page should be treated as the preferred version when duplicate or similar content exists. I use them to consolidate ranking signals, avoid internal competition, improve crawl efficiency, and clarify which URLs should be prioritized for indexing.

For example, an ecommerce site may use canonical tags to consolidate parameter-based URLs or faceted navigation pages to a primary product or category page. But if a canonical tag is applied to the wrong template, it could unintentionally tell search engines to consolidate an entire group of important pages elsewhere.

Canonical updates may look simple, but mistakes can be difficult to spot once they are deployed across a site. I take time to review canonical targets and validate the implementation so I do not send conflicting signals that cause important pages to lose visibility or fall out of the index.

3. Robots.txt file changes

The robots.txt file controls how search engines and other crawlers access content on a website. I usually recommend robots.txt changes to improve crawl efficiency, prevent low-value content from being crawled, or limit access to specific site sections.

For example, I may recommend blocking filtered URLs, internal search results, or other pages that consume unnecessary crawl resources. When implemented correctly, these updates help focus crawl activity on more important content.

The risk comes from rules that are too broad, misplaced, or copied from the wrong environment. A single directive can block important sections of a site from being crawled. Accidentally deploying a staging robots.txt file to production can also disrupt how crawlers access live content.

Because robots.txt changes can affect large parts of a site, I test rules carefully, review the proposed changes against the intended URL patterns, and verify the implementation after launch. Even a small robots.txt edit can have sitewide consequences.

4. Internal linking changes

Internal linking helps search engines discover content, supports priority pages, connects related topics, and guides users through a website. My recommendations may include updating navigation, adding contextual links, consolidating content hubs, or improving pathways to key pages.

As websites evolve, internal linking often needs cleanup. Removing important links, creating orphaned pages, linking to staging environments, or accidentally pointing users and crawlers to non-public URLs can all hurt discovery. Large navigation updates can also change how easily search engines reach important content.

That is why I always look closely at scope. A navigation update may touch thousands of pages, making it far riskier than adding a few contextual links to a small group of priority pages.

5. Site migrations

At some point, every SEO team deals with a site migration. It may happen because of a rebrand, a domain change, a redesign, or a move to a new CMS. When planned well, migrations can improve user experience, support long-term SEO performance, and benefit the business.

They are also inherently risky because they often combine several technical SEO changes at once. Redirects, URL restructures, canonical tags, indexing directives, content updates, and internal linking changes may all happen during the same launch. With that many moving parts, even a small oversight can affect crawling, indexing, and visibility.

Even a well-planned migration can run into problems if changes are not documented, tested, reviewed, and validated throughout the process. I rely on pre-launch QA, post-launch testing, and ongoing monitoring to catch issues before they have a lasting effect on performance.

Working across teams to ensure success

Technical SEO updates often require multiple teams to work together. I may need input from content teams, in-house developers, external agencies, product managers, and analytics teams before a change is ready to launch.

Clear communication is essential. I make recommendations straightforward, build testing and QA into the process, and define success criteria before launch. I also want a plan for quickly identifying and resolving issues if something goes wrong.

Communicating recommendations effectively

Whether I am discussing a recommendation directly with developers or documenting it in a structured ticket, I make sure the issue is clearly defined, examples are included, and the required changes are easy to understand.

Clear documentation helps me set expectations, explain scope, identify affected URLs, and define the expected outcome. It also gives teams a place to ask questions, raise concerns, and flag limitations before implementation begins.

Testing in development environments

Whenever a site change is made, I want it tested thoroughly before launch. A development environment gives me a place to validate the implementation, ask questions, and provide feedback while there is still time to adjust the work.

Post-launch testing and monitoring

Sometimes a change that works perfectly in development behaves differently after launch.

That is why I am ready to validate the implementation as soon as changes go live. Post-launch checks help me identify issues quickly, begin troubleshooting immediately, and monitor the impact before small problems become larger ones.

Balancing opportunity and risk

Most technical SEO recommendations are designed to improve crawling, indexing, or site architecture. When I implement them correctly, they can significantly improve how search engines access, understand, and evaluate a website.

But implementation usually depends on multiple teams working toward the same goal. As a recommendation moves from audit to production, misunderstandings, assumptions, and overlooked details can create unintended consequences.

That is why I see technical SEO as more than finding opportunities. I need to understand the issue, evaluate the potential impact, weigh the development effort, and manage the risk of implementation.

No technical SEO change is completely risk-free. But with thoughtful planning, clear communication, thorough testing, and ongoing monitoring, I can catch issues earlier, reduce their impact, and roll out high-impact changes with the caution they deserve.

Inspired by this post on Search Engine Land.

July 3, 2026
Why Technical SEO ROI Is So Hard to Prove and Fund
Six months ago, a core update could have crushed my website. But it did not.

It did not because my team had already fixed canonicals, redirect problems, duplication issues, and JavaScript rendering gaps eight months earlier. It was the kind of unglamorous technical work that often lands with an engineer or developer because the ticket has been sitting at the bottom of the list.

And I do not really have proof. What I have is experience from years in SEO and the ability to recognize that the site had the same warning signs I have seen on sites hit hard by similar updates.

Traffic could have been cut in half. It was not.

There is no parallel internet timeline where I skipped the work, so there is no clean way to confirm what would have happened. There is no record of the disaster that never arrived.

That is why technical SEO ROI is so hard to prove. I see it as an inference problem with no control group, even though the industry often treats it like a reporting problem we can solve with one more tool.

The internet doesn’t stop

When I work in digital, I am working inside at least two open systems: the internet and the market. I could add a third if I count the maturity and expectations of internet users. I could add a fourth if I count my own website infrastructure. In reality, there are even more moving parts than that.

The point is simple: the environment I am trying to measure is always shifting, expanding, shrinking, and changing shape. There is no fixed “before” state I can pin down, and there is no clean way to model what would have happened if I had done nothing. Bayesian forecasting and similar methods can help, but they are still educated guesses.

A technical change might improve visibility today. If I make that same change six months later, it might do very little. That could happen simply because Google changed its crawl budget behavior or adjusted how it reads websites.

Cause and effect do not always stay close together in SEO. Google recrawls and reindexes on its own schedule, so the impact of a technical fix may land long after the release. By then, the result is spread across a recrawl cycle and the clean before-and-after comparison I would want for a proper test has already blurred.

As with SEO overall, there is a lot I cannot control. If I tried to track every change across the web that might influence my site, I would end up with sleepless nights and a lot more gray hair.

Technical SEO adds another layer because these changes rarely ship in isolation. It is almost never, “I made one change to the website.” It is more often, “Thirty fixes from five teams are going live on Thursday so we still have people around on Friday if something breaks.” Please do not ship on Fridays.

A lot of technical SEO also keeps the site above water. I am managing technical debt, staying current with regulations, and adapting to new releases of codebases, platforms, and frameworks. True enhancements matter, but even those can be difficult to isolate.

Technical work is closer to insurance or public health than a standard growth campaign. I usually realize how important it was only when it stops working. Much of technical SEO is disaster prevention, not new-city construction. I cannot invoice for an earthquake that did not happen.

The control group was never there

Another reality is that many technical changes, whether SEO-led or not, are sitewide because they have to be. There is no control group. Render pipelines, crawl budget, and site speed touch everything at once, so there is no untouched slice of the site left to compare against.

Two examples make this clear.
- Sunsetting 301 redirects more than a year old: The server stops reading every redirect line on every page load. The benefit is crawl and resource efficiency, but that benefit is mostly invisible in analytics.
- A migration done right: The win condition is “we did not lose traffic.” Maybe the line stays flat. Maybe it ticks up slightly. Migration work usually becomes obvious only when it fails.
My only comparison is the past, and the past existed under different external conditions. Time becomes the problem. I can compare relative movement, incremental change, and long-term trends, but the outcome shifts based on which metrics I choose and which assumptions leadership brings into the conversation.

When I can, I want to run a proof of concept. In practice, that means something close to SEO A/B testing: choose a segment, make the change there and nowhere else, measure the result, and decide what to do next. But that is not always possible, and it requires a different kind of buy-in.

I am also working in a search environment where LLMs make more things probabilistic. Answers are personalized, discovery paths are less predictable, and many of the measurements I have relied on are less deterministic than they used to be.

So I keep it relative

There are two levels of relative thinking I come back to: how I prioritize technical work and how I measure its impact.

The way I prioritize the work helps determine the impact I am trying to create.

When I prioritize technical SEO, I start with impact. How much of the website does the issue affect? How much of that impact lands on priority sections or priority pages? After that, I move into the usual scoping and grooming conversations with development teams.

For me, impact is the anchor.

Measurement and reporting are harder. A lot of the SEO industry, myself included, is now rethinking how we measure almost everything, not just technical SEO. LLMs have accelerated that shift and left many of us in an uncomfortable middle ground.

I do not have a perfect “what would have happened if…” comparison for my own website. But I do have competitors. Watching how competitor sites respond to global events, especially Google updates, is probably the closest I can get to that missing counterfactual in technical SEO. It is ROI by proxy, sitting close to share of voice.

And the funding

Technical SEO is infrastructure. It is insurance. If I am struggling to get it done or funded, I need to look closely at how I am framing the work.

At its core, I see technical SEO as insurance against the shocks of an open system. I should treat it that way. It is not always a direct revenue driver.

Yes, technical SEO can produce meaningful improvements and help the line move up and to the right. But the workhorse, the 80%, the majority of the discipline, is keeping the engine running. The work does not always promise upside. It lowers the odds and the cost of getting hit. The core update that did not sink the site is the claim that paid out.

That is why I recommend talking to finance. I want to understand how finance teams quantify, value, and evaluate insurance, security, and infrastructure.

Then I can start looking at technical SEO that way. More importantly, I can start talking about it that way.

Technical SEO is growth resilience. It is the foundation my flywheel cannot move without, not an investment I should be apologizing for.

Inspired by this post on Search Engine Land.
July 3, 2026
Unlocking Hidden SEO Insights Through Server Logs

I’ve discovered that server logs hold a treasure trove of information for large websites, often uncovering technical SEO issues before they impact rankings. They offer insights into how search engines interact with our site, where we might be wasting crawl budget, server response times, and the accessibility of critical pages.

Unlike Google Search Console or third-party SEO tools, server logs capture every single request made by search engines to our infrastructure. It’s surprising how many organizations overlook analyzing them, thus missing out on valuable technical SEO data.

SEO teams often place their trust in tools like Google Search Console, Bing Webmaster Tools, and various third-party crawlers, which rely on data samples, delayed reporting, or simulated crawls. Server logs, however, document direct interactions between crawlers and our infrastructure, which is crucial for websites with a vast number of URLs.

Logs record every server request, and when used for SEO purposes, the most revealing entries come from search engine bots like Googlebot and Bingbot. These records create a detailed history of how our site gets crawled over time.

Most technical SEO problems start as crawl inefficiencies. I’ve seen scenarios where search engines request a page but receive unexpected responses, or they follow complex redirect chains, contributing to delays and inefficiencies.

Server logs clearly expose these inefficiencies. For instance, on large ecommerce platforms, logs might show that crawl resources are wasted on parameterized URLs, while important product pages are overlooked.

Retaining logs over time provides historical visibility into trends related to migrations, infrastructure changes, and platform redesigns. This ongoing visibility is something Google Search Console does not offer.

For instance, large sites often compete internally for crawl attention, and search engines don’t treat all pages equally. Logs can reveal if our valuable category pages are getting the right amount of attention or if outdated URL structures are still consuming resources.

Without these logs, many crawl inefficiencies might remain hidden. The crawl data in logs also assists us in understanding which sections of our site need optimization for better crawl efficiency and response timing, influencing SEO and even our infrastructure.

It’s amazing how log file analysis can differentiate between temporary issues and persistent infrastructure problems, helping us focus our efforts where it truly matters.

Having extensive log data enables us to monitor site migrations effectively, understanding crawler behavior pre- and post-deployment to ensure a smooth transition.

Operating without retaining server logs is like flying blind. Logs bridge the gap that many SEO tools cannot fill, providing a comprehensive view of crawler behavior and interactions with our web infrastructure.

Inspired by this post on Search Engine Land.

June 9, 2026
Boost Your SEO: Harness Schema Markup for the Agentic Web

I’ve discovered that AI agents heavily rely on structured data to understand and interact with my content. Embracing schema markup is essential to thriving in the emerging agentic web.

Schema markup has become pivotal in SEO and Generative Engine Optimization (GEO) conversations. I learned that both Google and Bing utilize structured data to fuel AI overviews, and platforms like ChatGPT incorporate it for product suggestions.

The evolution towards the agentic web means AI systems interact directly with websites on our behalf. It’s not just about understanding content; they need schema markup to interpret and act on it. This makes it clear why schema is becoming an integral part of the agentic web’s infrastructure.

In the traditional search landscape, schema markup enhances visibility by making my content eligible for search engine results page (SERP) features. It aids search engines in understanding entities better, thereby influencing how results are presented to users.

AI agents go beyond by leveraging schema markup to understand relationships and relevance. They assess if content is actionable enough to be recommended or used for task completion. This knowledge helps them determine if my content is trustworthy.

With structured data, my website becomes easier and cheaper for AI systems to process. Parsing unstructured HTML is more costly compared to clean, structured data, especially as large language models (LLMs) work within finite context windows and escalating inference costs.

Sites that simplify content interpretation are more attractive to AI agents as these systems expand. This simplification becomes critical for ensuring my content is accessed and utilized effectively.

I understand that NLWeb, built on schema markup, plays a vital role in the agentic web’s infrastructure. Microsoft’s open-source initiative, NLWeb, enables websites to integrate AI-powered conversational interfaces, transforming them into AI apps for natural language queries.

Developed by R.V. Guha, NLWeb connects with my existing schema markup, leveraging structured formats like Schema.org. This allows both humans and AI agents to interact seamlessly with the web.

Incorporating structured data like RSS with NLWeb ensures a real-time, interactive experience for AI agents, making my site truly ‘agentic’. The transition from humans browsing to AI agents querying underlines the significance of these initiatives.

For someone like me aiming to optimize for the agentic web, schema markup is a game-changer. It enables my site to be more than just readable, allowing for direct, real-time interactions through NLWeb’s capabilities.

NLWeb uses AI tools to create natural language interfaces, enhancing how my content can be queried and interacted with. It doesn’t require a complete rebuild of my existing content structure, just good order in my schema markup.

By prioritizing completeness, automating processes where possible, and utilizing JSON-LD, I can make steady progress in schema optimization. It’s crucial that I view schema as a comprehensive graph across my site, improving reliability and trust for AI agents.

Ultimately, adopting schema markup and understanding its evolving role in the agentic web is vital. As AI systems evolve, content that aligns with their preferences will reap ongoing benefits.

Inspired by this post on Search Engine Land.

June 1, 2026
Discover Google Chrome Lighthouse’s New AI Scan Feature

I’ve recently discovered that Google has introduced a new feature in Chrome Lighthouse to check for llms.txt files. Though Google mentions that llms.txt isn’t necessary for AI search visibility, Lighthouse has started flagging sites based on their presence.

Google’s latest Lighthouse audits, under the “Agentic Browsing” category, now focus on a site’s usability for machine interaction. I find this interesting as it aligns with Google’s push towards better machine readability.

The new audits are part of Chrome’s evolving “Agentic Browsing” features, which analyze if sites are prepared for automated interaction. This concept came soon after Google issued guidance on AI search optimization, debunking the necessity of llms.txt files in their new guide on generative AI features.

What Lighthouse Evaluates Now. Lighthouse’s Agentic Browsing tests focus on how well my site is built for machine interactions, incorporating various deterministic audits as per Google’s documentation. These checks include:

– WebMCP integration.

– Accessibility tree integrity.

– Layout stability through CLS.

– Presence of an llms.txt file.

These audits help ensure that there’s a machine-readable summary at the site’s domain root. Google explains that without llms.txt, agents might take longer to understand a site’s main structure.

The impact of these audits doesn’t translate into a traditional Lighthouse score but into a fractional pass ratio related to agentic readiness signals.

The Tension. Interestingly, while these audits don’t directly affect SEO rankings, their mention in Google’s readiness checks could make SEOs reconsider their stance on llms.txt files.

Agentic Engine Optimization. Google’s approach aligns with insights shared by Addy Osmani from Google Cloud AI about Agentic Engine Optimization. Osmani emphasizes creating web content that is semantically structured, token-efficient, and easy for AI to process.

SEO vs. llms.txt. According to Google, creating llms.txt or similar files isn’t necessary for AI search success, as outlined in the guide on Mythbusting generative AI search. The AI systems can discover, crawl, and index a variety of file types encountered on the internet.

John Mueller from Google responded to concerns about the role of llms.txt in a discussion with Lily Ray on Bluesky, stating that the use of these files is more for functionality and not directly linked to search engine optimization.

Google’s Take on AI Agents. Besides llms.txt, Google’s Lighthouse guidelines place strong emphasis on accessibility and interface stability. The insight I gained is that AI agents heavily rely on the accessibility tree as their core data model, focusing on integrity and proper layout.

Ultimately, while Google indicates llms.txt isn’t needed for search, including such files might be beneficial for adapting to Google’s evolving tools that prioritize machine readability.

Further Exploration.

– Meet llms.txt, a proposed standard for AI website content crawling

– llms.txt isn’t robots.txt: It’s a treasure map for AI

– Does llms.txt matter? We tracked 10 sites to find out

Inspired by this post on Search Engine Land.

May 20, 2026
Strengthen Stakeholder Support for Technical SEO Success

As someone deeply involved in technical SEO, I’ve realized that our projects thrive when I effectively communicate their value to both executives and developers.

What sets a great SEO professional apart from the rest is their knack for managing stakeholders. This skill is crucial in technical SEO, where projects often involve numerous teams, making it challenging to convey the importance of our work.

At the core of stakeholder management is the perceived value of our work. In technical SEO, this can be especially tricky. People outside the SEO realm might not immediately grasp the significance of optimizing a site’s internal linking or implementing schema markup.

The most successful technical SEO projects aren’t merely seen as SEO enhancements; they are viewed as vital to business outcomes like revenue growth, better conversion rates, and operational efficiency. By strengthening this connection, I find it easier to gain stakeholder support and showcase long-term value.

Why Aligning Technical SEO Work with Business Impact Is Essential

For most executives and development teams, technical SEO isn’t at the forefront. That’s why I ensure our technical SEO recommendations are directly linked to measurable business goals.

Take, for instance, a scenario where a company modifies its website’s CMS. The SEO implications of such a change are often overlooked on a project manager’s long list of priorities. It’s not until I clearly demonstrate the risks and their potential impact that SEO is properly emphasized.

Technical SEO initiatives can be inherently complex. They require a strong grasp of the company’s systems and teams, coupled with excellent communication and management skills.

Even though I might see this work as pivotal to the site’s SEO health, others might not appreciate its value if I’m talking in terms of crawl budget or index management. Drawing parallels to core business goals helps make our work more comprehensible and valuable.

Aligning technical SEO initiatives with business performance and goals is the best way for me to secure buy-in and highlight their impact.

Business Outcomes That Drive SEO Buy-In

Understanding the metrics and business goals is crucial for demonstrating how technical SEO can impact performance. Most organizations set corporate goals like expanding reach, boosting revenue, or entering new markets.

Revenue

For many businesses, whether a charity or a multinational, the bottom line is revenue. Connecting technical SEO efforts to revenue growth is a surefire way for me to secure support and illustrate its value.

Conversion

I can also show the value of technical SEO by linking it to conversion optimization. Studies indicate that a one-second delay in page load speeds can slash conversions by up to 7%.

Looking at core web vitals scores is important, but framing it as potential conversion loss grabs more attention from stakeholders.

Cost Reduction

I often notice that the potential for cost reduction is overlooked in SEO. Website visits incur hosting, infrastructure, and security costs that add up quickly with large sites.

Highlighting how technical SEO can reduce unnecessary expenses is key.

Dig deeper: How to prioritize technical SEO fixes by business impact

How to Strengthen Buy-In for Technical SEO Work

These four strategies help stakeholders better understand, support, and prioritize technical SEO projects.

1. Determine the Value of the Work

I never assume an SEO activity is worthwhile just because it’s a “best practice.” Every task I undertake ties directly to a business benefit and a core KPI.

Even if the immediate result is not new revenue, the activity should support revenue growth, conversion enhancements, or cost efficiency.

When I review and optimize internal site structures, I aim for improved rankings and increased organic traffic, translating to more conversions and revenue.

2. Identify How the Work Will Impact Company Goals

Once I understand the value of my technical SEO tasks, I align them with broader company or project goals to gain stakeholder approval.

For instance, if my goal is increased profitability in a certain region, and the task involves optimizing hreflang tags, I focus on how this supports the company’s goals, rather than technical specifics.

3. Communicate Effectively

Communicating SEO work’s impact is challenging, but breaking it down into ‘who, what, where, why, when, and how’ makes it understandable for stakeholders at all levels.

My goal is to make even the most technical aspects digestible by linking tasks back to business metrics everyone understands and values.

4. Prove the Impact Over Time

By consistently showing the positive results of technical SEO, I align our efforts with business objectives and make future conversations with stakeholders simpler.

After completing a project, I regularly review the outcomes to understand the impact, allowing for better future planning and adjustments.

Business Impact Matters More Than Technical Best Practices

Assumptions of what might enhance performance can sometimes miss the mark. Without revisiting previous implementations, I might not know what actually worked.

Just because something is hailed as “best practice” doesn’t confirm it will fit my site. Continually evaluating technical SEO outcomes helps reaffirm their business value.

Dig deeper: Advanced technical SEO tips: 14 technical SEO issues you’re missing

Inspired by this post on Search Engine Land.

May 18, 2026
Why Preparing for WebMCP Now is Crucial for SEO Success

I’ve seen many technologies come and go throughout my career. I used to chase after every new trend, trying to stay on the cutting edge. However, I quickly learned that this approach often cost me and my clients countless hours, with many technologies fading into obscurity. Does anyone remember Google Authorship?

I’ve realized that by waiting for wider adoption, learning from early adopters’ mistakes, and catching up quickly, I avoid wasting time and create more value. This approach has been invaluable to me.

However, some moments in technological advancement stand out—when being an early mover means not just succeeding but helping shape the future. The first people to realize the importance of PageRank and started building links can relate. WebMCP feels like another one of those pivotal moments, only larger.

The change we’re facing isn’t just about search engine mechanics or generative engine visibility. Discovery itself is evolving, and the entities performing this discovery are changing too.

I remember the age-old debate in SEO circles—should we focus on search engines or people? My answer is both. Yet now, this paradigm is shifting. What happens when discovery shifts from human-driven to being guided by AI agents?

When you ask ChatGPT a question today, it processes information, conducts additional searches, asks follow-ups, and delivers conclusions. The AI agent plans and decides for you, influenced entirely by its data sources and interpretive frameworks.

This evolution represents just one chapter in the ongoing story of discovery:

Discovery v1: Experiential interactions and word of mouth dominated.

Discovery v2: The written word took prominence in libraries and print media.

Discovery v3: The web spawned directories and search engines.

Discovery v4: Today, we see AI and LLMs increasingly aid discovery.

Discovery v5 (coming soon): Agentic systems will advance to perform actions autonomously.

Embracing Discovery v5 could offer us significant liberation—freeing our minds from mundane decisions, and enabling a focus on what truly matters.

The path to Trustable AI is underway. I now trust AI systems with everyday queries, relying on them more each time they enhance their capabilities.

Would I trust an AI to handle complex tax or health questions? Not entirely. Would I ask it to help plan dinner or schedule my day? Definitely.

This gradual trust expansion parallels past experiences with technology. As it grows, so does our reliance on agents to act on our behalf.

The tangible impact is visible: Automating grocery reorders or offering extraordinary travel deals are low-risk, high-reward changes.

The skepticism towards relinquishing control to technology is as old as technology itself. From fear of entering credit card details online to today’s reliance on smartphones and GPS, each shift was gradual but unstoppable.

WebMCP, which facilitates AI interaction with websites, is a browser-native web standard. It’s gaining momentum, authored by Google and Microsoft. It’s about easing AI’s job in understanding actions on websites, not replacing human interaction.

AI doesn’t need to infer tasks. WebMCP allows clear communication of a site’s capabilities, marking a shift like early schema markup days.

Engaging with this framework ensures your site is AI-ready, simplifying AI interaction.

WebMCP impacts discovery, influencing which sites AI agents prefer. Having your site AI-visible can make or break engagement in the emerging landscape of Discovery v5.

I’m taking advantage of this moment, despite my usual skepticism of early adoption—it feels different this time.

Inspired by this post on Search Engine Land.

May 15, 2026
Mastering Technical SEO: Prioritize for Real Business Impact

When I ran a crawl on my website, the report flagged hundreds of technical issues, all marked as high priority by my chosen tool. Sketching out a plan based on best practices, I felt the dread of impending communication with my developers.

But here’s the twist: Not all those ‘critical errors’ are really significant. I could spend weeks fixing high-priority technical issues and still not see a meaningful rise in traffic or conversions.

Some fixes seem urgent yet irrelevant, like a 404 error buried deep in the site architecture. It probably doesn’t deserve all the fuss.

Conversely, a minor issue in internal linking on high-value category pages might be holding millions of potential revenue back.

The real challenge in technical SEO isn’t in the fixes themselves but in understanding that not all issues hold the same weight. The myth that every fix is equally important persists. They simply aren’t.

Understanding the shift from issue-based to impact-based SEO is crucial for growth. Fixing everything isn’t the goal; fixing what truly moves the needle is.

Technical SEO tools are invaluable yet often create unnecessary anxiety. Crawl reports and health dashboards with flashing red flags often give the impression that every issue must be addressed immediately.

Yet, labeling something as a ‘critical issue’ due to a best practice violation doesn’t necessarily mean it impacts organic performance.

Time is often lost confusing technical correctness with search impact.

A site doesn’t need to be technically perfect to perform well in search engines. Equally, having an excellent CWV score doesn’t guarantee success if the wrong problems are prioritized. Some issues are cosmetic, some matter only at scale, and some relate to outdated best practices.

For me, successful technical SEO should focus on outcomes, not scores from various tools.

I often ask myself: Do this issue impact crawlability or indexing? Does it affect key sections of my site, like top-performing pages? Is there tangible evidence that it’s suppressing traffic or rankings? These questions help me prioritize effectively.

Equipped with the answers, I use a prioritization matrix to strategize effectively.

Some high-effort, low-impact fixes often drain my time without real benefits, such as fixing 404 errors that don’t affect user journeys or chasing minor Core Web Vitals changes that don’t benefit key pages.

By focusing on strategic internal linking or fixing canonical issues, I achieve low-effort, high-impact wins that significantly enhance discoverability and performance.

I’ve realized that the context of every site differs. Factors like business models and site architecture change the impact of specific SEO practices.

There’s no universal checklist for SEO priorities. What matters is understanding the impact of a fix on my site’s unique structure and content, and how it generates value from search.

A crawl report might show thousands of errors, but not all spell opportunity. At times, a single fix like a canonical correction or rendering issue overshadows everything else.

The essence of real SEO expertise is distinguishing between insignificant noise and impactful changes.

Inspired by this post on Search Engine Land.

May 14, 2026
How I Rescued My Website From a 90% Traffic Collapse

When my website’s traffic suddenly vanished, it felt like my online presence had evaporated overnight. Google had stopped indexing my pages, and I was desperate to reverse the decline caused by a botched migration.

This is my journey through a challenging case study of a multinational media organization that lost 90% of its traffic after a domain migration. By addressing the underestimated issue of soft 404 errors, we managed to liberate traffic potential across 13 country-specific domains.

While the events unfolded between 2021 and 2023, the lessons I’ve learned are timeless, and they apply to anyone facing indexing hurdles today.

The Sudden Traffic Plunge

In January 2022, the Brazilian version of a cryptocurrency news website completed a domain migration. Shockingly, instead of a minor drop, traffic plummeted drastically. A comparison between December 2021 and December 2022 showed a decline of approximately 90% year-over-year in both sessions and pageviews.

Before the migration, our old domain (xx.com.br) enjoyed between 15,000 to 25,000 clicks per day. After shifting to a new subdomain structure (br.xx.com), traffic fell to a sustained rate of just 2,000 to 4,000 clicks daily, and it stayed that way for over a year.

The migration occurred alongside three major Google algorithm updates in June 2021: a core update, a spam update, and a page experience update. The Brazilian site, however, showed no recovery even after facing temporary volatility due to these updates.

More Than Just Redirects: The Migration Dilemma

Generally, traffic recovery following domain migrations occurs within weeks or months as Google recrawls the site. Here, we observed no such recovery.

The crux of the issue was that Google continued crawling the old domain long after the migration. This split Google’s crawl budget, not consolidating on the new domain as expected, severely hindering our SEO efforts.

In mid-August 2022, after fixing the migration problems with the help of my SEO and IT teams, I noticed a slight positive change—a peak of 12 clicks and 37 impressions on August 29. This gave me a sign that Google was beginning to recognize the new domain appropriately.

Utilizing Facebook Prophet forecasting on our pre-migration data, we estimated that without migration issues, the Brazilian site could have exceeded 2 million monthly clicks by early 2022. Instead, the numbers were far less impactful.

Deciphering the Indexing Bottleneck

Resolving the migration unveiled a deeper issue affecting all 13 country domains: a massive backlog in indexing.

Google processes pages through four stages: Crawl, Render, Index, and Rank. For the Brazilian site, while crawling new articles took just about 2 minutes—acceptable for news—indexing took 24 hours. This delay was disastrous for timely cryptocurrency news.

The Magnitude of Migration Chaos: 513,000 Unindexed Pages

Google Search Console data in January 2023 highlighted severe indexing challenges across all domains, with Brazil alone having 513,369 pages categorized as ‘Crawled – currently not indexed’.

The ‘Crawled – currently not indexed’ status was troubling. These pages weren’t indexed because Google deemed them low quality or duplicate—yet potentially valuable content was left out of the index.

Upon investigation, I discovered that automatically generated thin-content pages, like currency converter URLs (e.g., “usd-to-thor”), were eating up the crawl budget, deprioritizing the domain.

Dealing With Soft 404 Explosions

Addressing the migration alone wasn’t enough, as a surge of soft 404 errors also demanded attention. These errors occur when pages return a success status (200), but lack meaningful content, mystifying search engines and squandering crawl budgets.

Soft 404s were proliferating across domains, including the main site and several international versions, complicating our SEO efforts further.

In France, this accumulation of soft 404 errors caused Google’s crawl requests to drop drastically, illustrating the pressing need to fix these issues.

Tackling the Crawl Budget Crisis

Understanding crawl budget is crucial. Excessively crawling ineffective pages depletes Google’s ability to find and index valuable content, particularly harmful for news sites needing prompt indexing.

By early 2023, our technical SEO was draining crawl resources, leading to slower indexing of fresh content and lost online visibility.

Implementing a Systematic SEO Fix

On January 31, 2023, I initiated an all-encompassing SEO strategy to target three priorities at once: Resolving soft 404s, optimizing the crawl budget, and refining Core Web Vitals, though the latter took a backseat to immediate indexing concerns.

Key actions included proper HTTP status code implementations for non-existing pages, optimizing URL structures, and improving canonicalization.

After the Fixes: Impressive Traffic Rebounds

The results were measurable just weeks later. In Brazil, ‘Crawled – currently not indexed’ pages fell by 57%, soft 404 errors reduced by 69%, and traffic began trending upward in early 2023.

International Recovery Highlights

In Germany, indexed pages surged, driving total daily clicks notably higher. Similarly potent results emerged across Poland and Spain.

Key Insights from My SEO Journey

I learned that handling indexing issues trumps almost every other SEO concern. No matter the quality of your content and backlinks, if your pages aren’t being indexed, your visibility won’t improve.

Moreover, ignoring soft 404s can quietly erode your site’s crawl budget, which silently undermines your SEO efforts until it becomes glaringly apparent in lost traffic.

Finally, detailed verification during domain migrations and focusing SEO strategies on regional requirements can make all the difference between an underperforming and a thriving website.

Inspired by this post on Search Engine Land.

May 12, 2026