I noticed that Google updated its canonicalization troubleshooting guide to clarify how long it may take for fixes to appear in Google Search results. According to the revised guidance, Google might keep pages in a duplicate cluster for up to two weeks after content issues have been fixed.
What changed. I found a new section at the top of the guide that explains the expected timeline for canonicalization fixes. Google now makes it clear that the process can take up to two weeks.
I also saw additional technical details about clustering. Google explains that pages need to be sufficiently similar before its systems can group them into a duplicate cluster and select one version as the canonical page.
Google’s updated canonicalization guidance sets expectations for SEOs: fixed pages may remain in a duplicate cluster for up to two weeks, while clearer content differences can speed reevaluation.
Here is the section Google added:
Why I care. This clarification gives me a more realistic timeline when monitoring canonicalization fixes. Once Google has processed an update, I know I may need to wait the full two weeks before deciding whether the change worked.
As AI reshapes search, every glowing path to discovery carries commercial value—turning SEO investment into a conversation about pipeline, risk, and customer acquisition costs.
That waiting period can help me avoid making unnecessary page changes while Google is still consolidating duplicate URLs and evaluating the appropriate canonical version.
Let me be blunt: SEO advice can sound completely made up to people who do not live in search every day.
When I say things like “change this canonical,”“don’t block that resource,” or “we need this content exposed in the rendered HTML,” I understand why someone outside SEO might hear it and wonder whether I am inventing rules on the spot.
That is one reason SEO still gets treated like black magic inside many organizations.
I have been pushing the idea of “un-nerding SEO” for years, but this is about something very practical: I use Google’s own documentation to earn approval, build trust, and help SEO work get prioritized.
Not because Google tells us everything. Not because every sentence in its documentation should be treated as gospel. I use it because documented evidence is much harder to dismiss than personal opinion.
When I need buy-in, the strongest argument is rarely “trust me.”
It is usually something closer to: “Google has already documented how this should be approached.”
The buy-in problem is usually not the recommendation itself
In my experience, most SEO recommendations do not die because they are wrong. They die because they are competing with everything else happening inside the business.
Dev sprints, product timelines, CMS limitations, legal concerns, brand standards, executive assumptions, and the classic “we’ve always done it this way” all have a seat at the table. SEO is rarely the only priority in the room, even when the recommendation is technically correct.
That is why I do not rely on “best practice says” or “from an SEO perspective” when I am trying to move work forward. Those phrases sound optional, especially to teams already balancing risk, deadlines, and competing requests.
But “Google has official documentation that supports this recommendation” lands differently.
It may not automatically win the argument, and it definitely does not mean the work will be prioritized tomorrow. But it changes the conversation from “the SEO person said so” to “we have official Google documentation explaining why this matters.”
Google documentation is not gospel
I know the objection already: “Are we really pretending Google tells us the full truth about how search works?”
Absolutely not.
Google’s documentation is not the complete truth of search. It has omissions. It simplifies complex systems. Sometimes it explains how Google wants site owners to behave, not every technical factor that influences organic visibility.
Google also writes for a broad audience, which means nuance gets smoothed out, edge cases get skipped, and the answer can be technically true without being the entire story.
So no, I am not treating every Google statement as if it were carved into stone and carried down from Mountain View.
But that does not make the documentation useless.
It makes it a starting point. A receipt. An official reference point.
It moves the discussion away from “I think this matters” and toward “Google has explicitly documented why this matters.” That distinction matters when I am asking someone else to approve and prioritize the work.
Documentation is especially useful with developers
This is where Google documentation often earns its keep the fastest. SEOs need developers, and I have learned that the quickest way to lose developer support is to treat every recommendation like a command instead of a requirement that needs to be implemented thoughtfully.
And yes, just in case it ever works, I still wish I could run this:
google.exe /disable-ai-overviews /please
Bummer. No dice.
Developers are not wrong just because they disagree with an SEO recommendation. Most of the time, they are optimizing for completely valid priorities: performance, code quality, technical debt, security, and avoiding the kind of production mistake that can take a whole site down.
But sometimes developers are wrong about how Google discovers, crawls, renders, indexes, or interprets content.
And telling a developer “you’re wrong” is a great way to make sure my ticket never sees the light of day.
This is where documentation helps. It removes some of the subjectivity and shifts the discussion toward how to implement the requirement inside the existing technical environment.
The point is that I now have an external source of truth to discuss. That is a much better conversation than two teams arguing from preference.
Documentation is also a client management tool
For client-facing SEO work, documentation helps me separate serious recommendations from “trust me, bro, I have a contact at Google” consulting.
Rows of illuminated data cabinets and paper files stretch into the distance, capturing the pressure on marketers to turn fragmented customer data into a smarter performance engine.
That matters even more when a client has been burned by bad SEO advice before.
Instead of saying, “We need to change this because it’s better for SEO,” I can frame the recommendation with evidence.
“Here’s what Google documents. Here’s where your current setup conflicts with that. Here’s the risk. Here’s the recommendation. Here is the estimated reward.”
That framing builds trust because it shows the recommendation is not relying on blind faith.
It also makes the SEO look less like a magician and more like an interpreter.
That is how I see the real role of SEO: translating Google’s documented needs into business and technical decisions that a team can actually act on.
Less black magic, more receipts
SEO has a reputation problem, and some of it is earned.
Too much SEO work is still explained with vague phrases and shaky confidence. I hear people say things like “Google likes this” or “this needs to exist for the bots” when the stronger version is: “Google documents this behavior here, and here is how it applies to our situation.”
That does not mean documentation alone creates buy-in.
Dropping a Google link into a ticket or Slack thread is not a strategy. I still have to translate what it means, explain the risk, connect it to business outcomes, and help the team understand why the recommendation deserves attention.
Google documentation will never replace experience, testing, or judgment. It will not tell me everything, and I should not treat it like the final answer to every SEO debate.
But it can make SEO easier to defend, easier to prioritize, and much harder for leaders to dismiss.
The best SEOs are not just the ones who know what to recommend. They are the ones who can prove why the recommendation deserves to be taken seriously.
Less black magic. More receipts. More results.
Google documentation may not be the whole truth, but I would rather show up to a buy-in conversation with official references than with “my buddy from Google told me.” Suuuure they did.
This post first appeared on the author’s website and is republished here with permission.
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.
I see advanced architecture as much more than a technical framework now. It shapes whether my content can be found, understood, and surfaced by search engines and AI systems.
That is why I am paying close attention to the next SMX Now on July 15, featuring Shari Thurow, co-founder, information scientist, and search director at the Information Architecture Gateway. She will explain how advanced architecture really works and where many AI, SEO, and site development workflows tend to fall short.
In this session, I will explore a five-phase framework Thurow has tested through decades of client work with organizations including Microsoft, Google Cloud, Abbott Laboratories, CVS Pharmacy, WebMD, Sony Music, the Library of Congress, Best Buy, and Merriam-Webster. I will learn how architecture decisions influence labeling systems, wayfinding networks, taxonomy, wireframes, and AI access to valuable content.
I also expect the session to challenge some long-standing assumptions, including the three-click rule, the idea that taxonomy is only a hierarchy, and the belief that AI can create effective wireframes without a deeper architectural model behind them.
Old search marketing tools give way to a faster, connected future, with data streams, AI icons, and a glowing search hub symbolizing SEO innovation and community growth.
By the end, I will have a practical framework for building sites that communicate more clearly with users, search engines, and human-centered AI systems.
I can finally say the page indexing report inside Google Search Console has been updated after a frustrating three-week delay. Instead of showing data stuck on June 11, 2026, the report is now displaying data through June 29, 2026.
The delay. I previously noted that the page indexing report had been frozen at June 11, which made it much harder to understand what Google was seeing across a site.
Now, as of Friday, July 3, the report is showing much fresher data, with updates running through June 29.
Page indexing report. I use this report to see which pages Google can find and index on a website. It also helps surface indexing issues Google may have run into while crawling the site.
I can access the report directly in Search Console over here, or by opening the Indexing section and selecting Pages.
The report shows indexed pages in green and not indexed pages in gray. I can also overlay impressions on the chart, then review the listed reasons explaining why certain pages on a website are not being indexed.
For more details on how the page indexing report works, I would refer to Google’s help document.
Why I care. If I was trying to diagnose why Google had not indexed specific pages over the past couple of weeks, the delayed report left me with limited visibility.
Now that the data has finally been refreshed through June 29, I can dig back into the indexing report, review the latest issues, and decide what needs attention next.
From January through June 2026, I reviewed more than 90 SEO agencies that have worked with luxury brands. I ranked each agency using five weighted factors that reflect both traditional search performance and the newer demands of generative engine optimization.
Notable Luxury Clients (35%): I gave the most weight to proven experience with luxury brands, because a strong record in this category is one of the clearest signs of real market expertise.
GEO/SEO Expertise Score (25%): I used a 1-5 score to evaluate each team’s depth of SEO knowledge and practical experience with GEO.
AI Visibility Score (15%): I scored how effectively each agency helps clients appear across AI platforms such as ChatGPT, Perplexity, Claude, and Google Gemini.
Leadership Experience Score (15%): I reviewed the SEO experience of each company’s senior leadership and translated it into a 1-5 score.
Average Reviews (10%): I factored in publicly available client review scores to understand how each agency performs in real client relationships.
After comparing the agencies across those criteria, I narrowed the field to five firms that stand out for luxury brands in 2026.
I ranked First Page Sage first because it is the only agency on this list that brings deep technical strength to both SEO and GEO for luxury brands. Its thought leadership content model is built to earn strong organic rankings while also creating the authoritative citations that help a brand appear when a buyer asks ChatGPT, Perplexity, or Gemini for a recommendation.
What stands out to me is that First Page Sage treats SEO and AI visibility as connected channels rather than separate workstreams. That matters in luxury, where buyers rarely rely on one source before making a high-consideration purchase.
Its work with luxury names such as Chanel and Milano Jewelry shows a strong ability to build both brand prestige and search performance. By leading with content that earns high-authority editorial backlinks, First Page Sage strengthens brand positioning while driving organic visibility that paid media cannot easily replicate. With nearly two decades of organic search experience and an early GEO practice, I see it as the most complete search partner on this list for luxury brands.
Notable Luxury Clients: Chanel, Milano Jewelry
GEO/SEO Expertise: 5.0
AI Visibility Score: 4.9
Leadership Experience: 4.8
Average Reviews: 4.9
Summary of Online Reviews
Clients describe First Page Sage as “the true expert in this industry,” with content that “takes thought leadership to the next level” and drives measurable outcomes. Reviews also point to campaigns that “generate high traffic and sales” across organic and AI-driven channels.
Amsive
I placed Amsive second because its technical SEO practice is one of the strongest I found in this review. The agency has also extended that technical discipline into LLM optimization, which makes it one of the few full-service firms here with a GEO capability that appears intentionally built rather than added as a late-stage service line.
For luxury brands with large, technically complex websites, Amsive’s combination of enterprise SEO depth and a growing AI search practice is a strong fit. I do see two limitations: its luxury vertical experience is narrower than several other agencies on this list, and SEO is only one part of its broader full-service marketing offering.
Even with those caveats, I would still consider Amsive a compelling option for brands that care most about long-term visibility across both organic search and generative search. Its ability to drive measurable performance at scale helps offset its narrower luxury portfolio.
Notable Luxury Clients: Voss Water
GEO/SEO Expertise: 4.2
AI Visibility Score: 3.8
Leadership Experience: 4.4
Average Reviews: 4.5
Summary of Online Reviews
Amsive’s “quality of work and investment in their clients” stands out in reviews, along with the “energy and enthusiasm” clients appreciate. For brands with complex technical needs, reviewers describe the agency as “a dependable execution partner.”
Relevance Digital
I included Relevance Digital because it is the most narrowly specialized agency on this list. The firm works exclusively with ultra-luxury brands and ultra-high-net-worth individuals, and that focus gives it a sharp understanding of how affluent consumers search, evaluate, and engage with luxury brands.
Its work with Bentley reflects client relationships that require more than technical execution. In my view, Relevance Digital’s strength is its command of luxury positioning and the specific expectations of ultra-luxury audiences.
For ultra-luxury brands that want an agency built entirely around their market tier, that vertical depth is difficult to match. The tradeoff is that its GEO capabilities are still developing compared with the stronger AI search practices higher on this list.
Notable Luxury Clients: Bentley
GEO/SEO Expertise: 3.9
AI Visibility Score: 3.6
Leadership Experience: 3.7
Average Reviews: 4.1
Summary of Online Reviews
Clients say they “couldn’t be happier with the work” and often highlight the agency’s “responsiveness” as a standout quality.
Hudson Rouge
I see Hudson Rouge as the strongest creative agency on this list, with a portfolio anchored by its well-known Lincoln campaign featuring Matthew McConaughey. The agency offers SEO, but GEO is not its primary focus.
That said, Hudson Rouge’s understanding of luxury brand storytelling and high-end consumer psychology is valuable. When paired with a more search-focused strategy, that creative strength could support authoritative content capable of earning visibility in search.
For luxury brands that want to invest primarily in creative media while treating SEO and GEO as supporting channels, Hudson Rouge offers brand craftsmanship that dedicated search agencies usually cannot match. I would evaluate it as part of a broader marketing mix rather than as a standalone search solution.
Notable Luxury Clients: Lincoln
GEO/SEO Expertise: 3.5
AI Visibility Score: 3.7
Leadership Experience: 4.2
Average Reviews: 4.3
Summary of Online Reviews
Hudson Rouge clients praise the agency for its “impressive” creative work and note that its campaigns “really understand the luxury space.” Reviewers also highlight its ability to “make brands feel premium” across every channel.
Amra & Elma
I ranked Amra & Elma fifth because the agency brings strong luxury audience fluency through social media and influencer marketing. Its client roster includes Swarovski and Bulgari, which reflects a meaningful level of experience with high-end brands.
Its SEO practice has grown substantially in recent years and now functions as a real offering rather than a minor add-on. However, I still view its GEO service as developing, especially when compared with agencies that have made AI citation and generative search visibility a core part of their search strategy.
For luxury brands that want a multichannel agency with access to high-end consumer audiences and a growing search presence, Amra & Elma offers an appealing mix of reach and brand fluency. Brands whose main priority is AI visibility will likely find stronger fits higher in this ranking.
Notable Luxury Clients: Swarovski, Bulgari
GEO/SEO Expertise: 3.4
AI Visibility Score: 3.2
Leadership Experience: 4.6
Average Reviews: 4.8
Summary of Online Reviews
Reviewers consistently describe the team as “nice, enthusiastic, and professional,” with expertise that ranks among “the best” in multichannel marketing.
I’m tracking an important AMP update from Google Search: users who tap AMP results will now be sent directly to publisher-hosted AMP pages instead of cached AMP pages shown inside Google’s AMP viewer.
A Google spokesperson told Search Engine Land, “Starting today, we are updating how we connect users to AMP pages from Search, taking them directly to the AMP host pages.”
Google also made it clear that this is not a ranking change. AMP content will continue to rank like any other webpage, and Google said the serving and ranking of AMP content in Google Search and Google Discover will remain the same.
From my perspective, the practical value here is mostly on the publisher side. By sending searchers straight to the AMP host page, Google says publishers should have simpler analytics management and tracking, along with less maintenance work when creating and supporting AMP content.
Google told us it will continue to support the open-source AMPhtml format, and it also posted the update in its Search documentation.
I also think it’s worth noting how much AMP’s role has changed over time. AMP has not received preferential treatment in Google’s Top Stories for a while, and AMP pages are much less common to encounter than they once were. Search Engine Land even turned off AMP in 2021.
It has been a long time since I’ve had much reason to cover AMP closely, but this change matters because it shifts the user journey back to publisher-hosted pages while keeping AMP’s ranking treatment unchanged.
Earlier this year, I made the case that the core fundamentals of international SEO still matter. I still believe that. Hreflang, localization, technical excellence, and market-specific content remain essential because search engines and LLMs still need to discover, understand, and connect content with the right audiences.
What has changed is the environment those fundamentals now operate in.
For decades, I watched multinational organizations treat markets as mostly separate digital ecosystems. Content created in one market usually stayed there, and governance focused on managing websites, content, and technical implementation across different regions.
Today, those boundaries are much harder to see.
AI systems can translate content, synthesize information from multiple sources, and increasingly sit between organizations and their customers. Information that once lived inside one market can now shape visibility, recommendations, and customer experiences across many regions.
As those boundaries blur, I see the governance challenge expanding. International SEO is no longer only about managing websites across countries. It now requires organizations to manage the knowledge, expertise, and information that search engines and AI systems use to represent them globally.
Why I believe the governance model must change
Historically, many website and localization decisions were built around operational efficiency. Headquarters created content, technology platforms, and standards for global distribution, while local markets adapted those assets for their own audiences.
That model worked because scale often outweighed the limitations of localization. Consistency improved, costs came down, and organizations could deploy content and technology across dozens of markets far more efficiently than local teams could manage independently.
The challenge now is that AI systems are changing what gets rewarded.
Scale and standardization still matter, but search engines and AI systems increasingly look for signals of expertise, relevance, and geographic specificity. Content that reflects local regulations, market conditions, customer expectations, and industry practices often provides context that translation alone cannot reproduce.
At the same time, AI systems can magnify inconsistency. Contradictory product information, conflicting entity definitions, inaccurate regulatory guidance, and fragmented technical implementations can create confusion across search engines, answer engines, and AI-powered experiences.
That is why I do not think organizations can optimize only for efficiency or only for localization anymore. They need governance models that protect global consistency while giving local markets room to contribute the expertise and context that increasingly drive visibility and trust.
Hreflang solved routing, not understanding
In my previous hreflang article, I argued that hreflang still belongs in an international search strategy, even in the age of AI. I stand by that view.
But hreflang does not decide which market perspective should be prioritized when AI systems synthesize information from multiple sources. It also does not determine which content demonstrates the strongest expertise when AI-generated answers are produced.
As search moves from retrieval toward synthesis, I believe organizations need to think beyond routing users to the right page. They also need to govern the knowledge that powers those answers.
What I would centralize
My simplest rule is this: if an activity creates enterprise risk when it is handled inconsistently, it should usually be governed centrally.
Technical SEO standards are a clear example. Search engines and AI systems do not evaluate websites one market at a time. They evaluate the broader ecosystem of signals an organization provides. CMS governance, structured data standards, entity definitions, AI crawler policies, measurement frameworks, and technical infrastructure all benefit from consistency.
Many international organizations have already faced a version of this problem.
Years ago, before hreflang existed, many global companies used IP detection to route users to the market website they believed was most appropriate. The problem was that Google primarily crawled from U.S.-based IP addresses. When Google tried to access French or Japanese content, it was often redirected to the U.S. site instead.
Individual markets could not solve that on their own because the routing rules affected every market at once. The solution required global governance with local input.
I see AI crawler management creating a very similar challenge today.
Organizations now have to decide which AI systems can access their content and whether those systems can reach the market-specific information they are meant to understand. For companies still relying on geographic routing, market gateways, or IP detection, the governance issue should feel familiar even if the technology is new.
The platforms have changed, but the lesson has not. Some decisions are too interconnected to manage market by market.
What I would localize
If technical infrastructure benefits from consistency, content benefits from expertise.
For years, multinational organizations followed a simple model: create content in the primary market, then translate, adapt, and distribute it globally. That approach delivered real efficiencies. It helped organizations scale content production, maintain brand consistency, and support dozens of markets with shared resources and common technology platforms.
Traditional search engines could lean on signals like hreflang and country targeting to understand regional relevance. AI systems increasingly evaluate the content itself. When multiple markets publish nearly identical versions of the same information, language models may treat them as variations of one source rather than distinct expressions of expertise.
To stand on its own, content increasingly needs market-specific signals such as local regulations, terminology, customer expectations, industry practices, and other forms of geographic specificity.
That is why I believe content ownership, audience research, local authority building, regulatory content, and market expertise should usually stay close to the market. The goal is not localization for its own sake. The goal is to make sure expertise comes from the people closest to the customer and that the content reflects the realities of the market it serves.
The strongest multinational organizations will still use global content frameworks, shared resources, and common technology platforms because those efficiencies remain valuable. The hard part is preserving those efficiencies while giving local markets enough space to contribute expertise that is visible, differentiated, and meaningful.
For years, organizations balanced scale against localization. Increasingly, I think they are balancing scale against representation. The markets that remain visible in AI-driven search experiences will often be the ones that contribute enough unique expertise to stand on their own, rather than simply echo the dominant market version.
What I think needs shared ownership
Governance ultimately comes down to accountability. Whether responsibility sits with a Chief Digital Officer, CMO, enterprise search team, or AI governance group matters less than whether ownership is clear. As search becomes more connected to marketing, technology, product, legal, and AI initiatives, organizations need clear decision rights, escalation paths, and accountability.
The companies that succeed will not necessarily be the ones with the largest SEO teams or the most advanced AI tools. I expect the winners to be the organizations that know exactly how knowledge is created, governed, validated, and represented across markets.
My practical rule for determining ownership
For me, the distinction comes down to risk and expertise.
Responsibilities that create enterprise-wide consequences when implemented inconsistently generally belong closer to headquarters. Activities that depend on local customer knowledge, regulations, language, or market conditions are usually best managed in-market.
Many of the most important decisions need both perspectives, which means they are best handled through shared governance.
10 governance decisions I would review with every global SEO team
The exact structure will vary by organization, but I would encourage most multinational companies to evaluate ownership across these areas.
Typically centralized
1. Technical SEO standards
I would centralize these standards to ensure consistency in crawling, indexing, structured data, and technical implementation across markets.
2. CMS and infrastructure governance
I would govern this centrally to prevent fragmentation while maintaining a common technology foundation.
3. Entity definitions and taxonomies
I would keep these consistent so products, services, brands, and organizational relationships are represented clearly across markets.
4. AI crawler and bot governance
I would establish consistent policies for crawler access, monitoring, verification, geographic routing, and exception management. Governance should usually sit with headquarters, while markets should still be able to request business-specific exceptions.
5. Measurement and reporting frameworks
I would centralize reporting definitions so markets are evaluated with comparable success metrics.
Typically localized
6. Market-specific content
I would keep creation and validation close to local teams so content reflects customer needs, regulations, terminology, market conditions, and the geographic signals that help AI systems recognize local relevance. Global content frameworks can still support that work where appropriate.
7. Audience and search behavior research
I would manage this in-market to capture differences in language, intent, customer expectations, and emerging market trends.
8. Local authority building
I would localize this work because market-specific expertise, trust, partnerships, citations, and visibility cannot be fully manufactured from headquarters.
Typically shared
9. Product and knowledge management
I would treat this as shared ownership because it needs global consistency as well as local validation, market expertise, and regulatory accuracy. Headquarters should define the framework, while markets validate that products, services, and policies reflect local realities.
10. AI visibility and representation
I would also make this shared. Headquarters should establish monitoring and escalation processes, while local teams validate market-specific accuracy and identify emerging issues in how products, services, and brands are represented across AI systems.
The new global SEO mandate
I do not think the objective is to centralize everything or localize everything. The real mandate is to place ownership where decisions can be managed most effectively, so the organization can balance consistency with expertise.
I see generative AI and automation creating both excitement and anxiety across the SEO industry. With 87% of Americans reading AI summaries, I believe any SEO team that is not adapting its toolset is already starting to fall behind.
When I move away from rigid enterprise tools and toward agile, AI-driven workflows, I can work faster, spot new search signals earlier, and show clients or internal stakeholders that I understand where search is heading.
In this guide, I’ll walk through what the old SEO stack looked like, what I now add to it, and how I combine both approaches without abandoning the fundamentals that still matter.
Here’s what an old SEO stack looks like
I still believe traditional SEO practices matter because generative AI search experiences continue to depend on core search ranking systems, quality systems, and the broader signals search engines have used for years.
That said, the classic SEO stack was built for a simpler search environment. It usually centered on rank tracking, keyword research, and technical site audits.
Rank trackers
For a long time, I treated keyword rankings as the heartbeat of an SEO campaign. I would add target keywords, monitor SERP positions, and expect higher rankings to translate into more search traffic. But rankings have become far more fragmented.
Now I need to pay attention to AI Overviews, local packs, shopping carousels, and many other search features that can change the value of a ranking completely.
A third-place local pack ranking, for example, may drive two or three times more traffic than a number one ranking in an AI Overview. That makes old-school rank tracking useful, but incomplete.
Keyword tools
Keyword tools still help me understand what people search for, how competitive a topic might be, and which queries match specific user intent. In the past, that information often felt close to a crystal ball.
I would choose keywords based on difficulty, search volume, intent, and other factors. The better the data, the easier it was to shape a campaign around the right opportunities.
The problem is that search volume has always looked backward. A keyword may have shown 10,000 monthly searches last month, but that does not mean it will perform the same way this month. Demand can rise, fall, or shift quickly.
Today, the bigger issue is opportunity loss. A keyword that generated tens of thousands of clicks in 2022 may now be answered directly inside an AI Overview. Even when search volume has not dropped, zero-click behavior can reduce the traffic I can realistically capture.
Site audit tools
I still rely on site audit tools because crawlers still crawl websites, interpret content, and surface technical issues. I need to know whether search engines can access, understand, and navigate the pages I care about.
Audit tools help me find broken links, redirect problems, missing metadata, slow pages, thin content, and other technical issues that can hold a site back.
But I do not expect crawl audits alone to tell me whether my content will appear in AI-driven search experiences. Technical health is necessary, but it is no longer the full picture.
Signals such as brand mentions can influence whether a site is included in LLM outputs from tools like ChatGPT, Claude, and Gemini. Many older site audit tools were not built to track those signals.
That is why I still keep parts of the old stack, but I now add tools and workflows that help me understand AI visibility, brand presence, and faster data-driven decision-making.
Here’s what a new SEO stack looks like
If I am optimizing only for Google’s traditional results, I am missing where search behavior is moving. Between the first and second half of 2025, LLM referral traffic grew by 80%. Conversion rates reached 18%, even though LLM referrals still represented 2% or less of total traffic in the dataset.
That tells me the channel is still small, but meaningful. Now is the time to build a stack that helps me understand, measure, and improve performance across AI-driven discovery.
LLMs
I want my site to appear in LLM responses, but I also use LLMs to strengthen my SEO process. These tools can support analysis, content review, competitor research, metadata refinement, and structured data work.
For example, I can connect ChatGPT with Google Search Console to automate SEO analysis, use Claude to refine copy and conduct content audits, or use Gemini to generate schema markup and compare competitor pages against my own.
I use the LLM that best fits the task, but I keep human oversight in place. These tools help me improve speed and performance; they do not replace judgment, strategy, or editorial review.
The biggest shift is speed. Large datasets that once took hours, days, or weeks to review can now be explored in minutes when I use LLMs carefully and integrate them into a repeatable workflow.
APIs
The old workflow often meant logging into dashboards, exporting CSV files, and cleaning everything in Excel. I still do that when needed, but APIs let me pull data directly from platforms like Google Search Console and Google Analytics.
APIs can sound intimidating, but LLMs make the learning curve easier. I can use them to help with authentication, JSON parsing, and the basic structure of repeatable data workflows.
Once I can connect to APIs, I can stop waiting on manual exports and start building faster reporting, monitoring, and analysis systems around the data I already use.
Lightweight scripts
Python scripts are now within reach for many SEOs, especially with tools like Claude Code and similar coding support inside ChatGPT or Gemini. I do not need to be a full-time developer to automate repetitive SEO work.
I can create scripts that pull top pages from Google Search Console, compare title tags against character limits, flag 30-day performance changes, or generate a clean CSV output for review.
Instead of waiting for a vendor to add the exact feature I need, I can build a small script that removes a bottleneck. A hundred-line script can replace hours of manual work without requiring another SaaS license.
I also like that scripts make the logic visible. If I hand the workflow to another teammate, they can inspect what the script does and understand how the output was created.
Notebooks and local workflows
SEO teams usually have data scattered across shared folders, Google Sheets, Notion docs, monthly CSV dumps, and long-running audit trackers. I have seen how quickly that fragmentation slows decisions down.
Notebooks and local workflows help me turn scattered files into a working system. A script can pull the data, an API can surface the signal, and an LLM can help interpret the results before the output lands in a notebook or spreadsheet.
The value is consistency. I get cleaner data formats, shared access, and documented logic instead of rebuilding the same process every time someone needs a report or audit update.
As search optimization becomes more connected to generative AI, I need workflows that scale. Local workflows help me keep data consistent while giving the team a faster way to act on what we find.
Creating hybrid workflows that mix old and new SEO stacks
I do not think the old SEO stack is obsolete. I also do not think the new tools replace everything. The strongest approach is a hybrid workflow that keeps proven SEO fundamentals while adding AI, APIs, scripts, and notebooks where they create real leverage.
Tool + custom script + AI layer
To build a practical hybrid workflow, I would start with a familiar audit tool such as Screaming Frog, then run a Python script that joins the crawl data with Google Search Console data.
From there, I could flag pages with high impressions and low clicks, send those pages to an LLM for title and intent analysis, place the output into a notebook or spreadsheet for editors, and turn approved recommendations into change logs.
Work like this used to take weeks, so many teams pushed it aside. At enterprise scale, the amount of data could easily become overwhelming. With a hybrid SEO stack, I can complete larger projects in a fraction of the time.
For me, the goal is not to chase every new tool. The goal is to build a more agile SEO stack that can handle today’s massive datasets, identify AI search signals, and help teams move faster without losing the core SEO basics.
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.
