Category: SEO

GraphRAG SEO: Why Entity-First Retrieval Matters

Making a brand machine-readable and improving its odds of being selected for AI-generated answers are important, but I see them as only part of the larger shift. Under the surface, a retrieval layer is changing how AI systems identify entities, connect facts, and decide which brands deserve to be cited.

That layer is GraphRAG. Once I understand how it works, “optimize for AI” stops feeling like a vague instruction and starts looking like a practical SEO strategy.

What is GraphRAG, actually?

GraphRAG extends traditional retrieval-augmented generation (RAG) by adding a knowledge graph. That graph helps AI understand entities and the relationships between them, instead of treating content as disconnected text fragments.

Microsoft Research introduced GraphRAG in 2024, and a broader ecosystem has formed around it since then. Instead of pulling from a flat sea of text chunks, GraphRAG builds a map.

In that map, nodes are the entities: a company, product, person, certification, location, or concept. Edges are the relationships between those entities, such as “offers,” “is certified by,” “authored,” or “operates in.”

I think of it as a system of things and the lines connecting them. When a model works from a map instead of a pile of scraps, it does not have to guess its way toward an answer. It can follow the relationships.

If the map says Entity A holds Certification B in Region C, the system can follow that path with confidence instead of inferring the connection and hoping it is right. That is why graph-based retrieval can produce more complete, better-grounded answers to complex questions with fewer hallucinations.

Microsoft described this failure mode in its GraphRAG patent, “Knowledge Graph Extraction” (US20250131289A1). The patent calls out a recall problem in naive RAG: a less prominent entity can disappear inside chunk embeddings, which means the system may retrieve nothing useful.

It also describes one of the fixes: entity resolution. When duplicate spellings or variations of the same thing are merged, the system can treat them as one entity instead of scattering their authority across several weak signals. That is one of the core building blocks behind graph-based retrieval.

Dig deeper: What patents reveal about the foundations of AI search

Why strong content still gets passed over

Traditional RAG works by chopping content into fixed chunks, turning each chunk into a vector, and storing those vectors in a database. When I ask a question, the system retrieves the closest chunks in vector space and passes them to a language model to generate an answer.

That can work for simple questions like “What is the capital of France?” It struggles with the questions that usually matter most in business: the multi-step questions.

If I ask a system to find a provider that offers a specific service, holds a specific certification, and operates in a specific region, naive RAG may stitch together an answer from scraps that merely sound related. It does not truly understand how the facts connect, so it guesses across the gaps.

When a system has to guess, the safer move is often to leave a brand out rather than risk saying something inaccurate about it. That is the part I think many SEO teams need to sit with.

This explains a common frustration: “Our content is strong, but AI systems still do not cite us.” The issue may not be content quality. GraphRAG consistently outperforms naive RAG on complex, multi-hop questions where vector search falls apart. That is where the visibility leak often starts.

In many cases, the machine could not reliably tell what the brand is, how its facts fit together, or whether it could trust those relationships enough to cite the brand by name.

The three problems GraphRAG is built to fix

I see GraphRAG lining up with three SEO problems that show up again and again: disambiguation, attribution, and relationships.

Disambiguation matters when the same entity appears under different names and gets counted as several weaker signals instead of one strong one. If “the firm,” “the agency,” and the actual brand name never resolve to a single entity, authority gets split.

Attribution matters when the fact survives but the credit disappears. When content is blended into an AI answer, the brand behind the original insight can easily vanish.

Relationships matter when the connections that give expertise meaning stay buried in prose instead of being declared in a way a machine can read.

If I have ever watched AI repeat something a company wrote without naming it, or credit a competitor for a specialty the company actually owns, I have seen all three problems in action.

What ties them together is simple: this is not only a content problem. It is an identity problem.

Same sentence, more machine-readable context

I want to make the idea of an entity concrete, because it can become abstract quickly. I will use one real-world example and one fictional example.

Start with Wayne Gretzky. Search his name in almost any AI client and I expect to see a confident summary: facts, former teams, records, and related links. That confidence is not luck. It is what a well-established entity looks like. His identity is nailed down and agreed upon across the web, so the system does not have to guess who he is.

Now imagine the opposite. Picture a goaltending coach in Moncton. I will call her Marie Tremblay. Her About page says: “Our head coach, Marie ‘Lefty’ Tremblay, has run elite goaltending camps across the Maritimes for 20 years.”

That is a good sentence. A parent understands it immediately. I would not rewrite it into robotic prose just to satisfy a machine. Optimizing for AI does not mean abandoning human voice.

The better move is to keep the sentence and add context around it. I need to make explicit what a human reader infers automatically.

That means clarifying that “Lefty” and “Marie Tremblay” are the same person. It means connecting Marie to the academy, to goaltending as a discipline, and to the Maritimes as the region she serves. It also means making “20 years” and “elite” verifiable claims rather than loose adjectives.

A human gets all of that from one sentence. A machine may not. My job is to close the gap between what the reader understands and what the system can verify, so Marie becomes as legible to AI retrieval systems as a famous entity like The Great One already is.

Why a flat triple is no longer enough

Knowledge graphs are built on triples: subject, predicate, object. “Acme offers consulting” is clean and useful, but it is flat. A bare triple cannot easily carry the high-stakes details that matter, such as whether the relationship is true, where it applies, who says so, and what evidence supports it.

The standards community is working on that gap. The W3C is extending the model with Resource Description Framework (RDF)-star, which allows site owners to make statements about statements. In practice, that means source, date, confidence, and other metadata can attach directly to a relationship instead of floating around as a disconnected claim. It is moving through the RDF 1.2 standardization process, with the RDF 1.2 Primer serving as a plain-English introduction.

Microsoft’s GraphRAG patent points in a similar direction. It pulls claims into a subject-action-object structure and weights relationships by how often they appear, instead of treating every stated link as equally reliable.

The practical lesson is clear to me: the future is not just saying two things are related. It is saying they are related and showing the proof in a form a machine can verify. A richer triple beats a flatter page.

The publishing layer is starting to respond

I am also watching the publishing layer, because that is where the shift is becoming visible outside the models themselves.

On June 1, the new open standard EntityMap launched a 33-day public consultation ahead of its July 1 launch. It was started by Fred Laurent, CTO of InLinks and Waikay, with backing from Dixon Jones. For anyone following entity SEO and the move from “strings to things,” those names matter.

The concept is deliberately familiar. Where sitemap.xml tells search engines which pages exist, an entitymap.json file tells AI systems what an organization knows: which entities it covers, how they relate, and where the evidence lives.

EntityMap aims at the same three problems: disambiguation, attribution, and relationships. It also builds in the richer-triple idea by allowing declared relationships to carry receipts, including a source URL, publisher, and timestamp.

I would treat it as a signal, not a mandate. EntityMap is a proposal in consultation, not a requirement. No major engine has committed to reading files like these, so I would not turn it into another box-checking exercise yet. The important point is that credible people are building entity-first publishing standards, and that direction is worth watching.

The honest state of GraphRAG

I do not think GraphRAG belongs in hype territory, because two realities keep it grounded.

First, GraphRAG is expensive. Building the map requires a language model to extract entities and relationships, and that is the costly part. By Microsoft’s own estimate, graph extraction accounts for roughly 75% of indexing costs. That LLM cost is one reason web-scale, real-time graph retrieval has not taken over everything overnight.

Second, the cost curve is bending. Recent research is attacking the infrastructure problem directly, including TurboQuant, a vector compression method from Google Research and NYU, presented at ICLR 2026. It reduces the memory footprint of vectors these systems traverse while preserving quality well enough to make the economics more interesting.

That does not mean every engine is running GraphRAG across the open web today. It means the economics are improving, which helps explain why entity-first standards are emerging now. I am cautious about anything framed as inevitable, but this shift makes practical sense.

Structured data still matters. Schema.org markup, a clean Knowledge Panel, consistent NAP, and strong entity signals are not going away. Entity-first work extends that discipline. It does not replace it.

My entity-first action plan

Here is how I would make this practical without betting everything on one standard.

Inventory entities, not just keywords. I would go beyond the search terms that historically brought traffic and list the things the brand genuinely knows about: products, services, people, methods, concepts, locations, and credentials. That becomes an entity map, whether or not it ever gets published as a formal file.

Disambiguate, then connect to the graph. I would claim and confirm the brand’s Wikidata entity and Google Knowledge Panel where possible. I would standardize naming, resolve variants, and keep sameAs links consistent across structured data. This is how “Lefty” and “Marie Tremblay” become one clear identity instead of two weak signals.

Make relationships explicit. I would use Schema.org types and properties such as Organization, Person, Product, knowsAbout, sameAs, and author so expertise is declared rather than implied. I would also mirror those relationships in internal linking.

Attach evidence to every claim. I would connect important facts to verifiable sources: named authors, first-party data, citations, documentation, and dated references. Graph-based systems increasingly need proof behind a relationship, not just the assertion.

Front-load defining facts. Retrieval still works through narrow windows, so I would place the clearest, most verifiable statement of what the brand is and what it does near the top of important pages.

Watch the publishing layer without overcommitting. I would read the EntityMap spec, follow how it develops, and decide later whether an entity index belongs in the stack. Schema.org work should continue either way.

Tie the entity map to revenue. I would map entity coverage to the queries and answer surfaces that influence leads, sales, margin, and retention. That helps leadership see entity work as revenue protection, not an academic exercise.

Measure what AI systems can recognize

Rankings and clicks still matter, but they describe the old search-page model. I would add metrics that show whether AI systems can recognize, trust, and cite the brand.

AI citation share measures how often the brand is named or cited in AI answers compared with competitors. I would track it monthly with an AI visibility tool.

Entity recognition asks whether priority entities have confirmed Knowledge Panels, Wikidata entries, and consistent identity signals. It is simple, but foundational.

Relationship completeness looks at how many priority entities have explicit, marked-up relationships and consistent sameAs links.

Attribution rate tracks how many core claims are backed by linked, verifiable evidence.

Answer-equity proxies include branded-query lift, assisted conversions from AI referrals, and lead stability as raw click volume softens. These business signals help show whether authority is compounding even when CTR is harder to read.

Where graph-based retrieval is heading

I expect graph-based retrieval to keep moving toward multimodal graphs, where text connects to images, audio, video, and structured data. I also expect more streaming and incremental indexing for live data, plus domain-specific ontologies for areas like medicine, finance, and law.

The move from strings to things is gaining momentum. The brands that stay visible will not simply be the ones publishing the most content. They will be the ones machines can understand without guessing, with clear entities, explicit relationships, and claims backed by evidence.

I do not need to wait for a new standard to launch before preparing. I can make a brand more legible now to systems that do not just read pages, but read what the brand knows. In the answer economy, I see the real battleground as identity, not just content.

Inspired by this post on Search Engine Land.

July 3, 2026
Fabrice Canel Leaves Microsoft Bing After Iconic Run

After nearly 30 years at Microsoft, I am seeing one of Bing’s most influential search leaders close a remarkable chapter. Fabrice Canel announced that he is retiring from Microsoft, writing on LinkedIn, “I am retiring from Microsoft, effective today July 1st.” He also reflected, “Today marks nearly 30 years with Microsoft. Thirty years…”

When I think about Fabrice Canel’s impact, I think first about the foundation of Microsoft Bing Search. He was responsible for indexing at Bing, including crawling, URL discovery, content selection, and content processing. Those areas are core to how search engines understand the web, and Fabrice helped shape them at massive scale.

He was also the person behind the IndexNow initiative, and he played a major role in creating and powering Bing Webmaster Tools. For anyone working in SEO, publishing, or technical search, those contributions matter because they helped make discovery, indexing, and webmaster communication faster and more practical.

I have watched Fabrice contribute far beyond product work. He has spoken at countless industry events, including SMX, and has written extensively about how search works, how sites can perform better in Bing, and how search is evolving with generative AI. He helped run one of the world’s most important search engines, while also giving the SEO community tools, education, and direct insight.

In his retirement message, Fabrice addressed fellow Microsoftees, engineers, attorneys, marketers, webmasters, publishers, SEO champions, product leaders, journalists, people across search and AI, and even friends at Google. His note was warm, personal, and full of gratitude for the people who shaped his Microsoft journey.

He described his three decades at Microsoft as a wonderful adventure, from solving real business problems with IndexNow to helping webmasters and publishers thrive in the constantly changing world of SEO and AI. He thanked colleagues, partners, publishers, and the people he trained and mentored, saying they are ready to carry the mission forward.

Fabrice also shared that, after many conversations with family and friends, he decided to take advantage of Microsoft’s Voluntary Retirement Program. His message ended with the same sense of warmth and storybook style that many in the industry have come to associate with him: gratitude for Microsoft, confidence in the Bing team’s future, and a final wish that everyone stay curious, keep innovating, and make content easier to find.

Why do I care so much about this? Because Fabrice has been a true friend to the search industry. His work will live on through the products, systems, and initiatives he helped create, and his willingness to share knowledge has made a lasting difference for SEOs, publishers, developers, and search professionals.

I know Fabrice has trained a team to continue the work, and I believe Bing remains in good hands. Still, I would be lying if I said I am not sad to see him retire. It has been an honor to work with him and learn from him over the years, and his legacy at Microsoft Bing will be felt for a long time.

Inspired by this post on Search Engine Land.

July 3, 2026
Google AI Mode Recipe Links Give Publishers a Boost

I’m seeing Google make recipe results in AI Mode more publisher friendly with a new visual treatment that gives recipe creators more visibility. For some recipe responses, Google is now showing details such as the creator name, recipe ratings, and the number of ingredients.

What is new. Google’s Robby Stein said AI Mode now includes “prominent links at the top of responses with useful details and images,” including creator names, ratings, and ingredient counts. From my view, the key shift is that Google is trying to make recipe sources easier to recognize and visit directly from AI Mode.

I also noticed that Google has been testing top stories carousels in AI Overviews, although that feature does not appear to be live yet.

What it looks like. The new treatment places recipe links, images, and useful recipe details more prominently in the AI Mode experience, giving users a clearer path from the AI-generated response back to the original recipe page.

Previously. Back in March, Robby Stein announced earlier changes to recipe results in AI Mode. At the time, he said Google had heard feedback and was making updates to better connect people with recipe creators across the web.

I see this latest update as part of Google’s effort to address concerns around AI recipe slop and to make original recipe content more visible when people search for cooking ideas through AI-powered results.

Why I care. Recipe bloggers, and content creators more broadly, have been frustrated that Google’s AI experiences often send less traffic than traditional search results. This update suggests Google is trying to encourage more searchers to click through from AI Mode to the publishers and creators behind the recipes.

If Google continues adding more clickable link units into AI search experiences, I think it could help ease some of the tension between publishers and Google. The bigger question is whether these changes will drive enough meaningful traffic back to recipe sites and other content creators.

Inspired by this post on Search Engine Land.

July 3, 2026
How AI Search Is Redefining Global SEO Ownership Now

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.

Inspired by this post on Search Engine Land.

July 3, 2026
My New SEO Stack: Tools I Use for Faster AI Search Wins

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.

Inspired by this post on Search Engine Land.

July 3, 2026
How I Find Who Is Using My Brand in Paid Search Ads

I know competitive brand bidding is now a common PPC tactic, but that does not mean I treat it as harmless background noise. When competitors, affiliates, coupon sites, or misleading advertisers show up on branded searches, they can inflate CPCs, divert high-intent traffic, and confuse people who were already looking for my brand.

I have seen how much difference visibility can make. Industry examples show that brands often uncover meaningful CPC inflation once they start tracking competitor bidding, affiliate activity, and trademark misuse. In documented cases, brands reduced branded CPCs by 25% to 75% after identifying infringing advertisers and enforcing their policies.

In this guide, I walk through how I monitor branded keywords, identify who is advertising on them, and decide what actions may be available based on the evidence I find.

Choosing Keywords So I Do Not Miss Hidden Activity

When I want to find out who is using my brand in search ads, I start by deciding which keywords I need to monitor.

The biggest mistake I try to avoid is watching only my exact brand name. That is a useful starting point, but it rarely shows the full picture. Some advertisers deliberately target brand-related coupon, discount, review, or alternative queries because those searches often come from high-intent users and attract less scrutiny.

For example, someone searching for “Brand coupon” or “Brand discount code” may be much closer to buying than someone searching for the brand alone. Those queries often attract coupon affiliates, loyalty sites, and unauthorized advertisers trying to intercept branded traffic.

I also pay attention to searches that include terms like “reviews” or “alternatives,” because those queries can bring in competitors and comparison sites that position themselves directly against my brand.

Misspellings matter too. Some advertisers target spelling variations because they are less likely to be monitored and may face less competition.

For a solid monitoring setup, I include my core brand name, “official page” and “login” variations, coupon and promo-code searches, review and alternative searches, commercial terms such as “buy,” “order,” and “sign up,” common misspellings, and localized versions of my brand name.

If I am using Bluepear, its built-in AI assistant can generate keyword suggestions from this kind of list and help me expand coverage faster.

The number of terms I monitor depends on the size of the brand portfolio, including trademarks, local branches, and product names. For many small to medium-sized brands, I would start with about 20 keywords and then expand as new risks, markets, and opportunities appear.

Choosing Locations and Monitoring Frequency

I do not rely on a single search from my office, on my device, at one moment in time. Search results are too dynamic for that. Two people searching the same branded keyword can see completely different ads and organic listings depending on their location, device, timing, and other variables.

I also assume that some advertisers may be trying to hide their activity. A fraudster or an affiliate violating my PPC policy might run ads outside normal business hours to reduce the chance of being caught. If I only check manually during the workday, I may never see those ads.

When I monitor branded search results, I look across the countries and markets where my brand operates, regional differences within those markets, mobile and desktop results, different times of day, and weekday versus weekend activity.

Frequency matters just as much as coverage. Some violations appear briefly and then disappear. Running checks multiple times throughout the day gives me a better chance of capturing activity that would otherwise go unnoticed.

Tracking all of these variables manually can become tedious, especially when a brand operates across multiple markets. Bluepear accounts for locations, devices, time zones, and redirects that can obscure the true destination of traffic. I can set the parameters once and gain continuous visibility without turning monitoring into a weekly time sink.

Reviewing Search Results and Recording Evidence

I do not assume every advertiser bidding on my branded keywords is breaking a rule. Competitors may be allowed to bid on branded keywords if they do not use my trademark in their ad copy. Affiliates may also be authorized to promote my brand under specific program conditions.

Still, I need to know when an advertiser’s behavior crosses the line from legitimate brand bidding into trademark misuse, policy violations, or customer deception.

The first signal I investigate is trademark use in ad copy. If the ad mentions my brand name in the headline or description, and my trademark rules or affiliate policies restrict that use, I treat it as a possible compliance issue.

I also look for misleading claims. Phrases that imply the advertiser is “official,” references to exclusive offers, or language that suggests authorization when none exists can confuse users and deserve review.

Coupon and discount promotions need special attention. I verify whether the advertised discount, promo code, or offer is legitimate, because some affiliates use expired, misleading, or fabricated offers to win clicks.

I also watch for impersonation signals. Some ads and landing pages are designed to resemble a brand’s official website. Even if the advertiser does not directly claim to be my company, that kind of presentation can still confuse users and divert branded traffic.

Because advertisers can change ad copy, pause campaigns, or remove landing pages at any time, I collect evidence quickly. I record the ad copy, SERP position, triggering keyword, location, URLs, redirects, landing page content, and timestamps.

Bluepear can handle this automatically by compiling a report with the relevant details, which makes follow-up easier when I need to contact an affiliate, review a competitor’s behavior, or escalate a trademark issue.

Identifying Who Is Behind the Activity

Sometimes I cannot immediately tell whether an advertiser is a competitor, an affiliate, a coupon site, or something riskier. Branded search results often include multiple participants with different motivations, so I need to understand who I am dealing with before I decide what to do next.

I look for patterns. A direct competitor domain usually points to competitor bidding. A coupon or cashback page may indicate an affiliate, coupon site, or loyalty site. Affiliate network tracking links often suggest affiliate activity, although they can also appear in more questionable setups. Product comparison pages often point to competitors or comparison publishers.

Other signals raise the risk level. If an ad uses my trademark, claims to be “official,” sends users through multiple redirects, promotes coupon codes I cannot verify, or lands on a page that imitates my brand’s design or messaging, I investigate more carefully.

No single signal gives me a definitive answer. I combine multiple pieces of evidence before drawing conclusions. Once I know who is advertising on my brand terms, I can move beyond detection and decide whether their activity aligns with my policies and business goals.

What I Do Next

After I identify who is advertising on my brand terms and review their ads, the next step is choosing the right response.

Competitor Brand Bidding

Not every competitor bidding on my branded keywords requires immediate intervention. Before acting, I ask how often the competitor appears, which keywords they are targeting, whether they are using trademarked terms in ad copy, and whether they are sending users to comparison content or direct offers.

In many cases, I monitor the activity and evaluate its business impact over time. Documenting patterns helps me establish a baseline, which can support future compliance reviews or legal conversations if escalation becomes necessary.

Affiliate Violations

If an affiliate is bidding on restricted branded keywords or violating program rules, I gather evidence and contact the affiliate or network. My workflow is straightforward: document the violation, verify the affiliate ID, share the evidence, request removal or corrective action, and apply program enforcement measures if needed.

Screenshots, timestamps, and redirect data make those conversations much easier because I can show exactly what happened, where it happened, and when it was detected.

Trademark Misuse

Trademark-related issues require careful review. I look for unauthorized trademark use in ad copy, ads that create confusion about brand affiliation, impersonation attempts, and misleading claims that the advertiser is an official brand representative, partner, or reseller.

The right response depends on the circumstances, internal policies, and applicable laws. In many jurisdictions, competitors are generally allowed to bid on trademarked keywords. However, ads that confuse users about the advertiser’s relationship with my brand may raise trademark or unfair competition concerns, depending on the facts and local law.

The advertising platform’s policies matter too. Google allows advertisers to bid on trademarked keywords, but it may restrict trademark use in ad text when a valid trademark complaint is submitted. Google also prohibits ads that use trademarks in a confusing, deceptive, or misleading way.

Before I take action, I collect as much evidence as possible, including screenshots, detection timestamps, URLs, redirects, and landing page content. Once the facts are documented, I may contact the advertiser directly, submit a trademark complaint to the advertising platform, send a cease and desist letter, or escalate through legal channels if necessary.

Why I Keep Monitoring Brand Search

The main lesson is that branded search protection is not a one-time audit. Affiliates can activate and pause campaigns throughout the month. Some violations appear only on weekends, outside business hours, or in specific markets. An advertiser that disappears today may return next week with new ad copy, a new domain, or a different affiliate account.

That is why I treat brand protection as an ongoing process. Occasional searches are not enough. I need consistent monitoring and a repeatable investigation workflow that shows who is appearing on my brand terms, how they operate, and whether action is warranted.

If I want easier visibility into my branded search landscape, Bluepear helps identify issues earlier, respond faster, and make more informed decisions about protecting traffic and advertising investments.

Inspired by this post on Search Engine Land.

July 3, 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
My 120-Minute Weekly SEO Workflow That Drives Results

When one person is responsible for paid campaigns, landing pages, reporting, email, social posts, sales requests, and last-minute website updates, I know exactly what usually happens to SEO: it waits.

I have seen this play out on small marketing teams over and over. Everyone knows SEO can bring in qualified demand, reduce dependence on paid media, and support buyers long before they fill out a form. The problem is that SEO rarely feels urgent until traffic drops, rankings slide, or something breaks.

That is why I like a simple 120-minute weekly SEO workflow. It gives me a practical way to protect visibility, find opportunities, improve high-value pages, and turn search data into business impact without pretending I have unlimited time.

Why I keep SEO simple on lean teams

When SEO falls behind, I rarely see effort as the real problem. The bigger issue is usually competing priorities and a lack of clear prioritization.

On a lean team, SEO is one tab among 20. The person responsible for organic growth may also be sending newsletters, briefing designers, updating landing pages, and pulling the report leadership wants by Friday.

Then the advice starts piling up: fix technical issues, publish more, build topical authority, refresh old posts, add schema, improve Core Web Vitals, build links, optimize for AI search, and keep going. Most of that advice may be valid, but no small team can do all of it in one week.

The question I come back to is not, “What could I do?” It is, “What is the highest-leverage thing I can actually finish this week?”

I also try to avoid the reporting trap. It is easy to spend an entire SEO block looking at rankings, traffic, impressions, clicks, CTR, conversions, competitor movement, and keyword shifts. Then the hour ends and nothing ships.

For a small team, reporting has to be short enough to leave room for action. The goal is to decide what to fix next, not to build another dashboard.

Why 120 minutes can be enough

I do not try to run a lean team like an enterprise SEO department. If I audit everything, track everything, collect endless keywords, and ship nothing, I have not improved organic growth.

The point of time-boxing is to force a decision. Every weekly session should end with one or two changes that improve visibility, traffic quality, or conversion potential.

In my 120-minute workflow, I focus on four outcomes: finding what is already working, fixing what is blocking performance, improving the pages closest to revenue, and turning search data into next week’s actions.

I am not trying to “do SEO” for two hours. I am using two focused hours to make decisions and ship work that has a realistic chance of moving the business forward.

My 120-minute weekly SEO workflow

0-15 minutes: Check organic data

I start with a pulse check so I can catch problems before they turn into bigger performance drops.

I look at Google Search Console clicks, impressions, CTR, and average position. I also check organic conversions or assisted conversions in GA4, top landing pages gaining or losing traffic, branded versus non-branded movement, and any indexing, crawling, or manual action warnings.

What I do not do is turn this into a full reporting session. This is not a board deck. I only want to answer one question: is organic visibility moving in a direction that needs action?

My output is a short weekly note: the biggest organic win, the biggest organic concern, one page or query to investigate, and one action to take this week.

15-35 minutes: Find query opportunities

Next, I look for the easiest opportunities in Google Search Console. The richest ones are often queries ranking in positions 4-15 with real impressions. Those pages are already close, and a focused improvement can help them move.

I also watch for pages with strong impressions but weak CTR, queries climbing week over week, and rankings where the current page only partially matches search intent.

I resist the urge to build a long keyword list. Instead, I pick three things: one page to improve, one query to answer better, and one title or meta description to test.

For example, when I reviewed search data for a local accounting client, several queries kept appearing around tax help for freelancers, small-business tax mistakes, and the difference between an accountant and a bookkeeper.

The obvious reaction would have been to write three new articles. Instead, I rewrote one service page around freelancers, added a short FAQ based on those queries, and linked it to an existing bookkeeping article. One page served three search intents, which was far more useful than three unfinished drafts.

35-60 minutes: Improve one money page

This is the most important part of the workflow. I define a money page as any page close to revenue, pipeline, bookings, sales, demos, or consultations.

Money pages can include product pages, service pages, category pages, comparison pages, demo pages, consultation pages, pricing pages, and high-intent landing pages.

My weekly goal is not to optimize the entire website. It is to improve one important page in one meaningful way.

I ask what the buyer needs to believe before converting, what objection is missing, what proof would reduce hesitation, what comparison the buyer already has in mind, and what query the page almost satisfies but does not fully answer.

A meaningful update might be adding three FAQs based on real queries, improving the H1 and introduction, adding comparison language, including proof points, linking to a case study, clarifying who the offer is for, improving the CTA, or adding a short “how it works” section.

That is SEO work, but it is also conversion work. The best page improvements usually help both search engines and buyers understand the value faster.

60-80 minutes: Fix one technical or indexing issue

Technical SEO can take over the full two hours if I let it, so I stay focused on impact.

The question I ask is simple: what could stop an important page from being discovered, understood, indexed, or trusted?

That usually points me toward issues like priority pages not being indexed, broken internal links, redirect chains, duplicate or missing titles on key pages, incorrect canonicals, schema errors on important templates, or valuable pages buried too deep in the site.

I want one of three outcomes from this block: a fix shipped, an issue assigned, or a clear developer brief.

For example, if I find that ecommerce collection pages are not indexed because of incorrect canonical tags, documenting the affected URLs and writing a clear developer brief may be more valuable than publishing another generic article.

80-100 minutes: Improve internal links

Internal linking is one of the fastest SEO wins I can create because it does not require new content.

It helps search engines understand which pages matter, helps users continue their journey, and helps informational content support commercial outcomes.

Each week, I look for links from high-traffic articles to money pages, links from product or service pages to supporting guides, links from older articles to newer strategic content, and opportunities to use clearer anchor text.

If an article ranks for “how to choose accounting software,” I do not want it to be a dead end. I want it to guide readers toward a comparison guide, a relevant case study, and a demo or pricing page. The traffic is already there, so I try to make it more useful.

100-115 minutes: Turn one search insight into messaging

I do not want search data to stay trapped in an SEO silo. The best query I find each week is often a useful signal for the rest of marketing because it shows the language buyers actually use.

A query like “best CRM for small agencies” can become a comparison section on a landing page, a LinkedIn post, a sales email angle, and a paid search ad group.

A query like “is [product] worth it” can become a proof section, a pricing explainer, a “who this is not for” paragraph, or a ready-made answer to a sales objection.

When I share one search insight each week, SEO becomes more than a channel. It becomes a source of customer intelligence.

115-120 minutes: Choose next week’s priority

I end with a decision, not a long list. I choose one clear priority for next week based on business impact, search demand, ease of execution, current performance gap, and proximity to revenue.

The template I use is: “Next week, my highest-leverage SEO action is [X] because [Y].”

For example: “Next week, my highest-leverage SEO action is updating the pricing page because it gets non-branded traffic, supports demo requests, and does not answer implementation cost questions.”

That is how I make SEO operational. The work becomes specific, owned, and easier to repeat.

A sample month for the workflow

To keep the workflow balanced, I like rotating the emphasis each week.

In week one, I focus on a revenue page. I update copy, add FAQs, improve internal links, check indexing and schema, and sharpen the CTA.

In week two, I refresh existing content. I choose one article with impressions but weak clicks or rankings, improve the title, add missing sections, update examples, link to money pages, and better match search intent.

In week three, I handle technical cleanup. I focus on one crawl, indexing, or template issue, such as broken links, duplicate titles, sitemap problems, or a developer brief for a higher-impact fix.

In week four, I turn SEO data into broader marketing assets. That may mean one landing page insight, one sales objection, one content brief, one paid or social angle, or one FAQ or comparison section.

This rotation keeps me from spending every week in dashboards, technical audits, or new content production while ignoring the pages that already have potential.

What I stop doing

Most small teams do not have a doing problem. They have a stopping problem.

I stop chasing every low-impact technical warning. I stop creating content just because a tool found a keyword. I stop publishing AI-assisted articles at scale without a strategy. I stop rewriting pages without a hypothesis. I stop optimizing low-value pages before revenue pages. And I stop treating rankings as the only score that matters.

Before I create new content, I review the pages I already have. The highest returns often come from pages that already rank on Page 2, already get impressions, sit close to revenue, and are one focused update away from doing more.

My test for any task is simple: if I cannot connect it to qualified traffic, conversions, discoverability, buyer education, or trust, it does not belong in the 120 minutes.

How I make it work without a dedicated SEO person

This workflow does not require a full SEO department. It requires one owner, a weekly rhythm, and a bias toward shipping.

A marketing manager can own prioritization and the weekly SEO note. A content marketer can update copy, FAQs, and page sections. A developer or web support partner can handle technical fixes. A paid search manager can share query and conversion insights. A founder or sales team can contribute objections and buyer language.

The owner matters most. Someone has to protect the 120 minutes, choose the priority, and make sure the session ends with an action.

Without ownership, SEO becomes everyone’s job and nobody’s job.

How I use AI to save time

I use AI to shorten repetitive SEO work, not to hand over strategy.

That might mean using a focused workflow to identify queries in positions 4-15, pages with high impressions and low CTR, search queries that should become FAQs, internal linking opportunities, or technical issues that should become developer briefs.

For agencies, client-specific assistants can reduce context switching by remembering each client’s services, priority pages, competitors, and customer objections.

The most useful AI workflows are narrow: a GSC opportunity analyzer, a money page refresh assistant, an internal linking assistant, a technical SEO brief generator, or an SEO reporting summarizer.

I do not want one generic SEO assistant trying to do everything. I want small workflows that help me move faster from data to decisions.

Consistency is the advantage

Small teams win SEO by doing the highest-leverage things repeatedly.

A 120-minute weekly SEO workflow will not replace a full strategy. It will not solve every technical issue, build every content asset, or uncover every opportunity.

But it gives me a practical way to protect visibility, learn from search data, improve revenue pages, and keep organic growth moving.

The mindset is simple: less auditing, more shipping, more buyer intent, less busywork, and more business impact.

Inspired by this post on Search Engine Land.

July 3, 2026
How I Use Google Query Expansion to Boost Visibility

LLMs have changed how people search and how Google responds. The SERP has not been limited to 10 blue links for a long time, but traditional search has usually centered on one core intent: the thing someone is trying to find.

Now, AI Overviews can create a full answer directly in the SERP. They do more than respond to the original query. They also bring in related terms, contextual refinements, and supporting information that help searchers make better decisions.

That is why I pay close attention to Google query expansion. When I understand how Google connects related searches, I can find visibility opportunities that competitors may miss.

What is Google query expansion?

I think of Google query expansion as Google broadening a searcher’s query so it can return more accurate results, especially for long-tail searches that might otherwise produce weak or limited results.

This can happen through synonyms. For example, Google may connect “budget” with “affordable” when the intent is similar.

It can also happen through intent expansion. Google may understand what my audience means even when they do not type the exact words I expected.

Related topic expansion matters too. Google can use similar searches and connected topics to surface content that supports the searcher’s broader need.

I do not use this as an excuse to stuff keywords into a page. Instead, I use query expansion as a research signal. When I see related searches that make sense, I can add useful supporting information and help my content rank for a wider range of relevant queries.

Here is a simple example. If I have an article about backyard chicken care and someone searches “What’s the average lifespan of a chicken?”, my page might appear even if I never used the word “lifespan.”

In that case, Google has decided the article is semantically relevant. Once I know Google has made that connection, I can add a helpful section about chicken lifespan. That gives the page a stronger chance to rank for the term and attract more traffic.

It can also improve the odds that my content appears in relevant AI Overviews.

The difference between Google query expansion and query fan-outs

Google query expansion and query fan-outs are related, but I do not treat them as the same thing.

Query expansion is part of traditional search. Google broadens a query with synonyms, related terms, and intent signals before results are generated. Because of that, my content can rank for searches I did not directly target.

Query fan-outs are part of AI Mode. They break a query into multiple related subqueries while the AI response is being generated. Because of that, my content can be retrieved as a source for an AI-generated answer.

So why does traditional query expansion still matter in a search world shaped by LLMs and AI Overviews?

Because the same semantic relationships that help Google expand a query can also influence which content AI systems retrieve during query fan-outs.

How I find query expansion opportunities

The first place I look is Google Search Console. It is one of the clearest ways to confirm whether query expansion is already happening for my site and my content.

My workflow is straightforward. I go to Performance > Search results, filter by a specific page, pull the full query list, and sort by impressions.

From there, I look for queries I never intentionally targeted. I pay attention to synonyms with meaningful impressions, question-based searches that may be especially useful for AI visibility, and broader keywords that are not currently addressed on the page.

I do not assume every discovered query deserves a content update. Sometimes a page appears for terms that are not truly relevant. When that happens, I audit the page and make sure the content is not drifting into unrelated topics that fail to match the promise of the SERP result.

How I plan better content with query expansion

Once I understand which expanded queries Google is connecting to my content, I use that data to strengthen the page instead of chasing isolated keywords.

I write for topic coverage

For a long time, strong SEO has been less about exact keywords and more about semantic relevance. I try to build coverage around subtopics, related questions, and adjacent ideas because that gives Google more context than a page built around one keyword alone.

I answer questions adjacent to the main topic

For example, if I am working on content for a company that sells chicken feed, I would not only explain the feed itself. I would also consider why the right balance matters and how the right feed can support chicken health.

I can find those adjacent questions by reviewing query expansion data in Google Search Console, checking tools like Ahrefs, and studying the SERP to see what supporting information Google is already surfacing for the topic.

I use expansion data to find content gaps

If Google Search Console shows that Google is pulling my page for a query I have not planned for, and that query is genuinely relevant, I treat it as a signal that the page may need more complete coverage.

Sometimes query expansion data includes odd or unrelated searches. I ignore those. But when I find adjacent queries that clearly strengthen the topic, I add them to the page in a useful and natural way.

I also revisit content regularly, usually at least once a quarter. New queries can appear, while others fade away. Since I am already keeping content fresh for the SERP, query expansion gives me another practical way to make each topic stronger.

How I use query expansion to improve AI Overviews visibility

AI Overviews often pull from ranking pages on a topic to build a more complete answer. Those answers can include semantic connections and supporting subtopics, not just the exact phrase someone searched.

That is why I cross-reference my query expansion data with the main keyword in the SERP. If an AI Overview includes supporting topics that are relevant to my page, I consider adding those topics to the content.

For example, I followed this process for a blog post titled “Tandem vs. Spread Axles in Trucking.” After filtering by impressions, I found that the page appeared for “tandem truck meaning,” even though that exact phrase was not specifically included in the content.

The page ranked first, but it was not included in the AI Overview for that specific query. That told me there was an opportunity.

Because the page already ranked well, I could use the expanded query and the supporting information in the SERP to create a section that better addressed both the query expansion term and the query fan-out patterns behind the AI Overview.

That is the value of this process. Query expansions can reveal supporting topics that strengthen traditional search visibility and improve the chances of being included in AI-driven results.

How query expansion helps my SEO strategy evolve

I use query expansion as a practical way to identify supporting topics and expand content coverage across search experiences.

As clicks become harder to earn, I want my content to appear across more relevant search moments. Broader visibility can strengthen brand awareness, support AI visibility, and keep my content in front of the people most likely to need it.

Inspired by this post on Search Engine Land.

July 3, 2026