There Is No Playbook Yet, and That's the Point
If you have spent any time reading vendor pitches, conference recaps, or LinkedIn threads about AI Search and the agentic web in the last twelve months, you have probably noticed a pattern.
Everyone has a methodology. Almost no one has a primary source.
The acronyms multiply: GEO, AEO, LLMO, AIO, and each one promises to be the framework that finally cracks the code. Most of them will not survive the next Chrome release.
This is the real reason senior SEOs and CMOs feel paralyzed about AI Search. It is not that Google moved their cheese. It is that nobody has yet written a credible playbook for AI Search and the agentic web, and the cost of investing six months of budget into a tactic that gets quietly deprecated is real.
The fear is not penalty risk. The fear is sunk cost.
Two recent Google artifacts get us closer to an honest answer than anything the vendor ecosystem has produced.
The first is the web.dev article "Build agent-friendly websites," published by the Chrome team and last updated on April 1, 2026. The second is the Search Off the Record podcast episode "How AI Is Changing Google Search and SEO," hosted by Martin Splitt with Nikola Todorovic, a long-tenured engineering lead in Google's Search organization.
Read together and cross-checked against the Search Central documentation they implicitly rely on; these two pieces are the closest thing to a primary-source playbook currently available.
They are not a complete framework, but a signal. The job of this guide is to read that signal honestly, separate what Google is actually asking for from what the market is hallucinating and turn the result into something a senior SEO or a CMO can act on without betting the budget on a tactic that will not survive the next Chrome release.
The operating frame to take into the rest of this document is simple: what is durable here is not the protocol, it is the principle. Build for legibility — to humans, to classic Search, and to agents — and you reduce the risk of having to redo the work in six months.
Everything that follows is a structured argument for why that frame holds, and how to operationalize it.
The AI Search Theory, Made Practical
Two sources, one thesis, and a provenance distinction that matters
Before any analysis, a note on whose voice is talking, because the market keeps conflating two distinct teams at Google and arriving at miscalibrated conclusions.
The web.dev article is published by the Chrome team. Its authors, Kasper Kulikowski and Omkar More, are framing AI agents as a new kind of website visitor and proposing UX-level recommendations to make sites legible to those agents. The framing throughout is "consider following." Nothing in the article is presented as a Google Search ranking factor. This is design and accessibility guidance, escalated by the rise of agentic browsing.
The Search Off the Record episode is the Search team explaining what AI features inside Google Search actually are, how they were built, and how they relate to the rest of the ranking stack. Todorovic talks about AI Overviews, AI Mode, fan-out queries, and the long arc of machine learning inside Search. He does not talk about WebMCP, the accessibility tree, or agent UX at all.
These two artifacts overlap thematically but answer different questions. The Chrome guidance is about how agents read your site. The Search guidance is about how AI features in Search find, rank, and synthesise content. Both matter but are not the same thing. Treating them as a single voice produces a roadmap with the wrong priorities, which is exactly what most GEO-style frameworks currently do.
The third source layer — the Search Central documentation, particularly the "AI features and your website" page — is the actual ranking-relevant authority. Where the Chrome article says, "consider following" and the podcast says "keep providing value," the Search Central documentation says, in plain prose, what is required for eligibility and what is not.
Agents are a new "user," not a new crawler
The Chrome team's central reframing is that agents are autonomous, interactive, reactive, and proactive; moreover, they are functionally distinct from the training-data crawlers that have been scraping the web for years. An agent visiting your site is doing so on behalf of a specific user with a specific goal, in real time. It needs to read, understand, and act.
To do that, modern agents read sites through three modalities simultaneously.
Screenshots: a vision model interprets the rendered pixels and identifies elements by visual cues like size, color, and proximity.
The raw HTML in the DOM: the agent parses the document tree, attributes, and structural relationships.
The accessibility tree: the browser-native semantic summary of the page that strips away visual noise and exposes roles, names, and states of interactive elements.
A useful analogy: imagine a tourist navigating a foreign city with a paper street map, a smartphone camera, and a local audio guide all at once. They do not pick one source. They triangulate. If the paper map is out of date but the audio guide is current, they trust the audio guide. If the camera shows a closed shop that the map says is open, they trust the camera.
Modern agents work the same way. Your job, as a site owner, is not to optimize for one of those signals. It is to make all three coherent, so the agent does not have to disambiguate.
This is why the seven recommendations the web.dev article lays out are not a new doctrine. They are accessibility canon, escalated.
Use semantic HTML on actionable elements.
Keep layouts stable.
Add cursor:pointer on anything clickable.
Wire labels to inputs.
Make interactive targets larger than eight square pixels.
Avoid transparent overlays that hide what looks tappable.
Reflect every action in a visible state change.
None of this is new. What is new is the economic stake.
A page that fails these checks is no longer just unfriendly to assistive technology and screen readers. It is also unreliable to the agent that a user has delegated a transaction to.
The challenge isn't simply understanding Google's guidance, it's also knowing whether the changes you make are actually improving your visibility.
Try Advanced Web Ranking free to track traditional rankings alongside emerging AI visibility, and see whether your SEO efforts are translating into real search presence.
Query fan-out, in Todorovic's own words
The single most consequential architectural shift Google has confirmed in the last two years is query fan-out.
In the podcast, Todorovic defines it directly: when a user enters a query, Google may identify additional search queries that yield results relevant to the original.
The system forks, retrieves results in parallel for multiple sub-queries, and combines them into a response. AI Overviews and AI Mode both use this technique. The Search Central documentation states it explicitly.
In plain language: a single prompt like "best family-friendly all-inclusive in Sardinia for August with toddlers and a celiac kid" no longer maps to a single keyword competition. It explodes into a parallel cluster of mini-searches — family-friendly resorts in Sardinia, August weather and crowds, toddler facilities and child clubs, celiac-friendly menus, transfer logistics from Olbia and Cagliari airports — and your URL competes for inclusion across each fork.
This kills the "one keyword, one URL" mental model. It also rewards a different kind of content architecture. A focused, deep page on the celiac-friendly buffet question can earn a citation in AI Mode even when it does not rank for the head term "Sardinia all-inclusive." Topical surface area beats “keyword density”. This is where the entity-and-cluster thinking that has been around since the early 2010s — and that I have personally been writing about under the Architecture of Authority frame — finally has an unambiguous mechanical justification, written by Google itself.
There is also a second-order implication.
Todorovic and Splitt note that user queries are getting longer and more conversational because users have figured out the system can handle vague, multi-clause prompts. The shape of demand is changing. Pages built for the older keyword-extraction model — short, competing, identical-shaped articles on the same head term — perform worse against fan-out than topically rich, sub-question-aware content does.
How Google decides what "better" means
One of the most useful passages in the podcast — and one that all three of the AI-generated reports I reviewed before drafting this guide underweighted — is Todorovic's description of how Google actually evaluates changes.
Search runs thousands of changes per year. Each change is built as an experimental prototype, tested against the production baseline through side-by-side comparisons, and reviewed by human raters using the published Quality Rater Guidelines. The statistical results from those reviews go into a launch review where engineers present to leads with decision-making authority. Even when the overall numbers improve, a clear pattern of losses can block a launch.
This matters because it grounds the abstract question — "what does Google define as quality?" — in an operational answer. Quality is what wins side-by-sides at scale, evaluated against the publicly available rater guidelines. It is not a single signal, not a black box, and not a hidden formula. It is a process. AI features in Search go through the same process. The implication for site owners is that the lever you can actually pull is the same lever the rater guidelines describe: experience, expertise, authority, trust, page quality, and how well the page meets the user's need. The mechanism is unchanged. The interface is new.
WebMCP, with calibrated expectations
The web.dev article ends with one forward-looking pointer: a link to WebMCP, a proposed web standard for letting websites expose structured tools that agents can call directly, instead of forcing the agent to manipulate the DOM through screenshots and clicks. WebMCP is co-developed by Chrome and Microsoft, currently behind a Chrome flag in early-preview status, and explicitly not a ranking factor.
The restaurant analogy: today, an agent reads your menu by photographing it (screenshots), by reading the printed text (DOM), and by listening to the waiter describe it (accessibility tree). WebMCP is the kitchen pass-through, aka a structured way for the agent to call orders without translation. When it works, it is faster, cheaper, and more reliable than the screenshot-and-click pipeline.
Where this leaves a senior practitioner: WebMCP is worth understanding now and worth piloting on a single critical transactional flow in the next six to twelve months. It is not worth betting your roadmap on it today. The signal Google is sending by linking it from the canonical web.dev article is directional, not mandatory. The right posture is informed optionality: build the muscle, prototype quietly, and be ready to scale when adoption reaches a threshold. Project Mariner, which Google had been positioning as the reference implementation for browser-resident agents, has been recently sunset, which is a useful reminder that specific products in this space can be deprecated even as the underlying architecture continues to develop.
AI Search Operational Insights
For the senior SEO
Three priority buckets, in dependency order. The order matters. Skipping bucket one to start on bucket three is the most common mistake in this space, and it is the mistake the web.dev article and the SOTR episode both implicitly invite by not foregrounding the technical-SEO foundations.
Bucket one: crawl, render, index — the foundations the source material under-emphasizes
If Googlebot cannot fetch, render, or index your priority pages, every recommendation downstream is moot. The web.dev article assumes a clean rendering pipeline. Real production sites rarely have one.
Crawlability beyond robots.txt. Most large sites have robots.txt configured correctly. Far fewer have audited their CDN and WAF rules for Googlebot interference, their faceted-navigation patterns for crawl-budget waste, their parameter handling for duplicate-URL inflation, or their response-code hygiene (real 404s versus soft 404s, 301 chains, 302 misuse). A clean robots.txt with a broken WAF rule blocking Googlebot from a CDN edge is a daily occurrence in the field.
Rendering, including JavaScript SEO. Googlebot's Web Rendering Service uses a recent Chromium build to render JavaScript. That does not mean every site renders correctly for it. Critical content trapped behind tab interactions, accordions, or client-side fetches that fire only on user action will not be visible to Googlebot. The URL Inspection Tool in Search Console is the cheapest way to see what Googlebot actually rendered. Use it on your priority templates before you do anything else. Recently, on an client website of mine, the internal team asserted that critical content was server-side rendered; the URL Inspection output showed it was not. This is a representative case, not an outlier.
Indexability and international integrity. Canonical conflicts, parameter handling, hreflang implementation, and noindex sweeps on priority templates. For multilingual and multi-regional sites, hreflang is not a nice-to-have, but the mechanism that prevents your en-GB version from cannibalizing your en-US version inside Google's index, which is exactly the kind of error that fan-out retrieval will surface and amplify, not hide.
Bucket two: page experience and rendering performance, reframed
Core Web Vitals are not a renewed topic. What is new is the reframing of why they matter for AI features. An LCP greater than 2.5 seconds is no longer just a user-experience tax. It is also wall-clock latency in an agent loop, where the user is watching a model wait. CLS in the red is no longer just a usability problem but a screenshot-stability problem: agents that snapshot a page mid-shift get the wrong button position and mis-execute. Performance is now also an agent-reliability tax.
The practical implication is that performance work is no longer a UX-team line item that competes with SEO priorities. It is an SEO priority, and increasingly an agent-readiness priority, with three distinct downstream stakeholders pulling in the same direction.
Bucket three: semantic and accessibility hygiene at template level
Apply the seven web.dev recommendations as template-level audit items, not as a site-wide sweep. Pick the top ten conversion-critical templates:
Homepage.
Primary category.
Primary product or service detail page.
Primary lead form.
Search results.
Checkout.
Account.
Contact.
Support.
Your highest-traffic editorial template.
Audit each one with Chrome DevTools' accessibility tree view.
Fix the failures:
Replace styled <div> elements acting as buttons with semantic <button> tags,
Add cursor:pointer where missing, wire <label for="..."> on every input,
Eliminate transparent overlays,
Stabilize the position of primary calls-to-action across template variants.
Ensure every interactive target exceeds the eight-pixel visible threshold.
These fixes are accessibility canon. They were also accessibility canon in 2010. The new economic stake is that they now also determine whether an agent can complete a task on your site. The deliverable is the same. The customer for it has changed.
For the CMO
Three uncomfortable conversations to have with the executive team. None of them are technical. All of them are strategic, and all of them belong on the CMO's desk, not the developer's.
Conversation one: brand and entity clarity is now technical infrastructure
Knowledge Graph integrity, sameAs alignment to Wikidata and Wikipedia, Organization and Person schema consistency across all owned properties; these used to be the SEO team's quiet hygiene work.
They are not anymore.
In a fan-out retrieval world, the entity layer is what the system disambiguates against. If your brand is a fuzzy match against a competitor in Google's index, you will lose citation share in AI Mode regardless of how much content you publish.
Fixing this is a CMO-level decision because it crosses brand, legal, communications, and technical SEO. Treating it as a pure SEO task underfunds it.
Conversation two: scaled commodity content is now a balance-sheet liability
Google's documented position is that AI-assisted content production is allowed if it adds value, and that scaled content abuse — using automation to publish thousands of low-value pages — violates spam policy.
Todorovic states the same principle in plain language in the podcast: just multiplying generated content because it is cheap and easy will not provide value. Splitt extends the point with a sharp consumer-side anecdote about technical articles that became spec-sheet paraphrases dressed up as journalism and lost his attention as a reader.
The CMO implication is direct. Volume-based content strategies, which several agencies still pitch as a way to capture AI Search visibility, are now a documented policy risk and a documented audience-attention risk.
The replacement is not less content. It is content with a defensible originality threshold — first-hand testing, original data, expert opinion, lived experience — and editorial accountability. That is a budget conversation, not a tactic conversation.
Conversation three: Google-Extended is a strategic call, not a technical-SEO call
Google publishes a separate user-agent token, Google-Extended, that controls whether your content can be used for training and grounding in Gemini and Vertex AI generative products outside Search. Google's documented position is that disallowing Google-Extended has no effect on Search inclusion or ranking.
This is therefore a brand-strategy decision, not a technical-SEO decision. Allowing it preserves your presence in the broader Gemini ecosystem. Disallowing it preserves stricter content control. Either is defensible. The wrong move is to default into one without a documented rationale, because the question will come back from legal, comms, or the board within twelve months and "the SEO team handled it" is not an answer.
The challenge isn't simply understanding Google's guidance, it's also knowing whether the changes you make are actually improving your visibility.
Try Advanced Web Ranking free to track traditional rankings alongside emerging AI visibility, and see whether your SEO efforts are translating into real search presence.
What The Source Material Misses Or Underweights
This section is deliberately standalone, because the gaps in Google's published guidance and in the AI-generated reports synthesizing it are themselves a form of information. Four gaps deserve naming.
Gap one: the technical SEO blind spot
All three deep-research syntheses I reviewed before collapse technical SEO into accessibility hygiene. Crawlability, rendering, indexing, and JavaScript SEO are upstream of every other recommendation.
The web.dev article assumes the rendering pipeline is clean. Real production sites rarely have a clean one. Translate in plain language: before doing anything, fix the crawlability and indexability your website may have.
Gap two: internationalization
Neither the web.dev article nor the SOTR episode discusses hreflang, locale-adaptive rendering, or how fan-out retrieval interacts with multilingual content.
For international travel brands, multinational manufacturers, and global e-commerce — which is most of the high-value AI-Search opportunity — this is a live and unresolved issue.
A fan-out cluster generated in one language may pull supporting links from a different-language version of the same brand if hreflang is broken, and the user lands on the wrong locale.
None of the official Google material currently addresses this directly... but I got you covered here on Advanced Web Ranking with this article about International AI Search SEO.
Gap three: the Chrome-versus-Search distinction
The web.dev article is from the Chrome team. The AI Features documentation is from Search Central. They are aligned but not interchangeable. The Chrome guidance is UX and accessibility framing, escalated; the Search guidance is ranking-relevant. The market reads them as a single voice. They are not.
Conflating them produces miscalibrated priorities, most often, over-investing in WebMCP experiments while leaving foundational crawl and render issues unfixed.
Naming the distinction explicitly is one of the few ways to defend a roadmap against pressure to chase whichever Chrome announcement made the rounds last week.
Gap four: agent operability is selection bias, not a ranking factor
Making your site agent-friendly does not make Google rank you higher. It makes you cheaper for agents to operate against, which means you are more often selected when an agent has a choice between you and a comparable competitor.
That is a different mechanism with different downstream consequences.
The lift, if it materializes, will show up in citation share inside AI Overviews and AI Mode, and in transaction-completion rates when agents act on user behalf, and not in classic ranking position.
Naming this distinction explicitly prevents the C-suite from expecting the wrong KPI to move.
The challenge isn't simply understanding Google's guidance, it's also knowing whether the changes you make are actually improving your visibility.
Try Advanced Web Ranking free to track traditional rankings alongside emerging AI visibility, and see whether your SEO efforts are translating into real search presence.
The AI Search Operational Workflow
Twelve weeks, four phases, explicit pass conditions. Run this sequentially on the site templates that drive the majority of revenue or qualified leads. Do not run it on the entire site. The cost-benefit ratio collapses outside the top conversion paths.
Phase one: Discoverability foundations (Weeks 1–2)
Goal: prove that Googlebot can fetch, render, and index your priority pages cleanly. Without this, every later phase compounds an underlying problem.
Audit robots.txt against Google's published common-crawlers list and verify CDN and WAF rules are not selectively blocking Googlebot via user-agent or IP-range filters. Use the Search Console URL Inspection Tool on every priority template to confirm the crawler sees what you intend.
Test rendering on every priority template with the URL Inspection Tool. Compare the rendered HTML output to the visible page. Note every piece of critical content that is missing — typically tab content, accordion content, content fetched on user interaction, and content gated behind authentication walls that should not be.
Audit canonical declarations, parameter handling, hreflang for multilingual properties, and the noindex directive coverage on priority templates. Soft 404s and 301 chains are common silent killers.
Verify Googlebot via the published reverse-DNS check, especially if you have recently tightened your WAF or migrated CDN providers.
Pass condition: every priority page returns HTTP 200 to Googlebot, renders its critical content visibly to Googlebot's Web Rendering Service, is indexable, and is not unintentionally blocked from snippet display.
Phase two: Semantic and accessibility hygiene (Weeks 3–6)
Goal: make your top ten conversion-critical templates legible to all three modalities — screenshots, DOM, and accessibility tree — that agents use to interpret pages.
Audit the accessibility tree on each priority template using Chrome DevTools. Industry reports indicate the full accessibility tree became the default Elements-panel view in Chrome 148; confirm against your current Chrome version. Log every interactive element that lacks a correct role, name, or state.
Replace styled <div> and <span> elements acting as buttons or links with semantic <button> and <a> tags. Where semantic HTML is genuinely impractical, supply explicit role and tabindex attributes.
Restore cursor:pointer on all interactive elements. Note that recent Tailwind versions changed this default — a frequent cause of regression in component libraries.
Wire <label for="..."> attributes to every form input, matching the input's id.
Eliminate transparent or near-transparent overlays that cover interactive nodes. Confirm every required interactive element has more than eight square pixels of visible area.
Stabilize the position of primary calls-to-action across template variants. The "Add to cart," "Buy," or "Submit" button should occupy the same DOM position and approximate screen coordinates regardless of category, variant, or context. This is a Cumulative Layout Shift issue, an accessibility issue, and an agent-reliability issue at once.
Verify that every user action produces a visible state change in the interface — no silent successes.
Run a structured-data parity audit. Schema must be a true representation of visible page content, per Google's General Structured Data Guidelines. Mismatch is a stated reason for rich-result exclusion.
Pass condition: the accessibility tree on every priority template exposes correct roles, names, and states for every interactive element on the user journey, and the structured data declared in the page matches the visible content rendered to the user.
Phase three: Content architecture for fan-out (Weeks 7–10)
Goal: shift content architecture from head-term coverage to topical surface area, organised around the sub-questions that fan-out retrieval will actually generate.
For your top twenty priority topics, observe AI Mode and AI Overviews directly. Document the sub-questions that surface, the supporting links Google cites, and the gaps where you could plausibly become a citation source. This is the closest available proxy for the fan-out queries Google's system is generating internally.
Restructure passage-level content for extractability. Lead each H2 and H3 with a self-contained, standalone answer. Use comparison tables where the user need is comparison. Use lists where the user need is enumeration. Avoid burying the answer beneath rhetorical preamble.
Build out topical surface area. Every distinct sub-question that fan-out surfaces should resolve to an indexable, internally linked URL on your site. Strong internal linking between the pillar page and the supporting URLs is what makes the cluster legible to retrieval.
Reinforce the entity graph. Organization, Person, Product, and where relevant LocalBusiness schema with sameAs links to authoritative external identifiers — Wikipedia, Wikidata, official social profiles, LinkedIn for individuals. This is what the Knowledge Graph and thematic-clustering operations match against.
Apply an originality threshold to every page in scope. If the same article could be produced in ten seconds by a chatbot with no human oversight and no first-hand evidence, it does not belong in the cluster. Google's documented position on scaled content abuse and Todorovic's podcast comments converge on this point.
Pass condition: every priority topic has a documented sub-question map, a coherent cluster of supporting URLs, and a visible originality signal on the pillar and lead supporting pages.
Phase four: Forward optionality and measurement (Weeks 11–12)
Goal: lock in measurement, governance, and forward-looking optionality without overcommitting to early-stage technology.
Make a deliberate, documented decision on Google-Extended. Capture the rationale so the next time legal, comms, or the board asks, the answer exists in writing.
Document a preview-governance policy. Decide which pages, sections, or non-HTML assets should allow full snippet preview, capped preview, or no preview, using nosnippet, data-nosnippet, max-snippet, and noindex deliberately.
Set up server-log monitoring for the distinct Google user agents — Googlebot for Search, Google-Extended for training and grounding, Google-NotebookLM for user-supplied URL fetches. Verify each via reverse DNS, since spoofing is common.
Configure Search Console performance reporting at the "Web" search-type level, which is where AI Overviews and AI Mode traffic is currently aggregated. There is no separate AI Mode performance report yet. Use sub-question citation tracking — manual sampling of which competitors appear for fan-out forks of your priority topics — as the operational proxy.
Optionally, evaluate WebMCP early-preview enrolment for one critical transactional flow. Treat this as a capability-building exercise, not a roadmap commitment. Re-evaluate when WebMCP graduates from Chrome flag to default-on.
Pass condition: every governance decision is documented, every measurement source is configured, and any forward-looking pilot has a defined exit criterion and a rollback plan.
Thresholds that change these recommendations
If Google publishes an explicit AI Mode performance segment in Search Console, recalibrate the measurement model around it (but this will probably never happen).
If WebMCP graduates from Chrome flag to default-on shipping, escalate WebMCP from one-flow pilot to roadmap commitment.
If the AI Features and Your Website documentation is updated to introduce specific markup or file requirements, re-audit the affected templates immediately.
If Google-Extended documentation is amended to indicate any Search ranking interaction, reconsider any blanket disallows.
The challenge isn't simply understanding Google's guidance, it's also knowing whether the changes you make are actually improving your visibility.
Try Advanced Web Ranking free to track traditional rankings alongside emerging AI visibility, and see whether your SEO efforts are translating into real search presence.
What this is, and what it is not
Strip the rhetoric away, and the message in the source material is consistent.
The door to AI Search is unchanged: indexable, snippet-eligible, technically sound pages, judged against the same quality criteria Google has been refining for years.
The lock now responds to three keys at once — humans navigating, classic Search retrieving, and agents executing. The keys are different. The door is the same.
What Google is not telling us, in any of the official material, is that there is a new secret schema, a privileged AI optimization file, a llms.txt requirement, or a way to game AI Overviews. The vendors selling those things are selling vapor. Todorovic's most direct prescriptive statement in the podcast is also his shortest: there is no magic wand. The advice is to keep providing value, master the new tools, and not multiply low-value content because it is cheap and easy.
The durable strategic position, then, is the same one I have been arguing for under the Architecture of Authority frame, with sharper edges and a faster clock. AI Search visibility is a downstream consequence of sound entity architecture, content depth, and technical legibility. It is not a separate discipline. It is not a new acronym. It is the same work, declined for a new surface (from this the differences and the nuances), executed against a tighter deadline and a more demanding evaluation environment.
A final note on epistemic discipline. The moment Google publishes a new doc that contradicts this analysis, this analysis updates. The moment a vendor's playbook contradicts a primary Google source, the vendor loses.
That is the operating principle: primary sources first, market noise second, and your own roadmap calibrated to what the source material actually says rather than to what the loudest voice on LinkedIn this week claimed it said.
Build for legibility. The protocols will change. The principle will not.
Article by
Gianluca Fiorelli
With almost 20 years of experience in web marketing, Gianluca Fiorelli is a Strategic and International SEO Consultant who helps businesses improve their visibility and performance on organic search. Gianluca collaborated with clients from various industries and regions, such as Glassdoor, Idealista, Rastreator.com, Outsystems, Chess.com, SIXT Ride, Vegetables by Bayer, Visit California, Gamepix, James Edition and many others.
A very active member of the SEO community, Gianluca daily shares his insights and best practices on SEO, content, Search marketing strategy and the evolution of Search on social media channels such as X, Bluesky and LinkedIn and through the blog on his website: IloveSEO.net.
