Forem: Dario Zadro

GEO Requires More Than SEO: The Technical Distinction Nobody Is Making

Dario Zadro — Wed, 29 Apr 2026 23:48:00 +0000

GEO is mostly SEO. But mostly is not all of it.

The conversation keeps collapsing into two useless camps. Camp one says GEO is just repackaged SEO with a shinier invoice. Camp two says SEO is dead. Both are wrong.

Here's the technical case for why.

Eligibility vs. Selection: The Distinction Nobody Is Making

Two completely separate problems are being treated as one.

Eligibility is whether an AI system can reach your content at all. Crawled, indexed, snippet-eligible. Google explicitly documents that to be considered for AI Overviews, a page must be indexed and eligible to show a snippet. If you don't clear that bar, nothing else matters.

Selection is what happens after retrieval fires. Of everything the system pulled in, which chunks actually end up in the LLM response?

SEO governs eligibility. GEO governs selection. These are sequential problems, not the same problem.

The data backs this up. A March 2026 Ahrefs analysis of 863,000 keywords and 4 million AI Overview URLs found that only 38% of cited pages ranked in the top 10 for the same query, down from 76% just seven months earlier. A separate BrightEdge analysis from February 2026 puts that overlap even lower, at around 17%.

So roughly two out of three AI citations come from pages a user would never see on page one. The AI is not drawing from what ranks. It's drawing from what it can use.

RAG: A Term the SEO Community Is Misusing

You can't open a LinkedIn feed right now without someone referencing RAG. Most of those posts are technically wrong.

Retrieval-Augmented Generation (Lewis et al., 2020) is a specific architecture. It combines what a model already knows from training (parametric knowledge) with documents pulled in at query time (non-parametric retrieved context). That's it.

RAG is not:

A synonym for "search API call"
The same thing as embeddings, which are a vector representation method used within retrieval, not the architecture itself
Something that always happens. Many queries get model-only responses with no retrieval at all

Retrieval is conditional, not constant. When someone tells you "rank well and you'll get retrieved," they're giving you advice that only applies to a subset of queries.

Not All Retrieval Runs Through Google or Bing

Each platform retrieves differently. This is where "just do SEO" advice collapses:

Google AI Mode / AI Overviews. Query fan-out across subtopics and data sources, with supporting pages identified during response generation. The citation set extends well beyond what ranked for the original query.
Claude. Runs on Brave Search, not Google or Bing. A 2025 analysis by Profound found 86.7% overlap between Claude citations and Brave's top organic results. Not indexed by Brave? Claude won't cite you. Doesn't matter where you rank on Google.
Perplexity. Runs its own continuously refreshed index using two distinct crawlers, after moving away from Bing Web Search API in 2022. Strong freshness bias: 90% of top cited sources answer the core question within the first 100 words (BLUF pattern).
Microsoft Copilot. Grounds through Bing APIs across three distinct modes.
OpenAI Assistants. Documents hybrid keyword plus semantic vector retrieval, query rewriting, parallel searches, and reranking. No search API involved.

Two distinct mechanisms underlie all of this that most agencies never separate.

The first is training data inclusion. Being present in the sources models learned from. Wikipedia, major publications, Reddit, high-authority industry sites. You build toward it through long-term brand authority and earning mentions across those sources. That's digital PR and link outreach. SEO under the hood. And Google has been parsing contextual relevance and brand mentions longer than most realize. But the real divergence is sentiment parsing across trained data and RAG methods. Feeding those systems is where SEO ends and GEO begins.

The second is retrieval-time inclusion. What happens when an LLM does live web retrieval during a prompt response. Results get re-ranked by the model based on probability and relevance. That retrieval step does not care much about rankings.

That second mechanism is what 90% of GEO tactics actually target. Even when practitioners claim otherwise.

Your brand appearing as a citation is an output address. It's not a retrieval receipt. It doesn't tell you how the content got there.

Fan-Out Coverage: The Most Underrated GEO Signal

A single user query gets decomposed into multiple sub-queries before retrieval even happens. Your content has to survive that fan-out, showing up across several rewritten versions of the original question, not just one.

A 2025 Surfer SEO study analyzing 173,902 URLs found that pages ranking for fan-out queries are 161% more likely to be cited in AI Overviews than pages ranking only for the main query. The Spearman correlation between fan-out coverage and citation likelihood was 0.77. And ranking for fan-out sub-queries alone was 49% more likely to earn a citation than ranking exclusively for the head term.

You can actually see fan-out in action. Open dev tools on any AI chat interface, fire a query, and inspect the Network tab. In Claude, you'll see sequential tool_use blocks in the JSON response payload showing your single query decomposed into multiple sub-queries in real time.

{
  "tool_use_blocks": [
    {
      "type": "tool_use",
      "name": "web_search",
      "input": { "query": "top SEO agencies Chicago 2026" },
      "sequence": 1
    },
    {
      "type": "tool_use",
      "name": "web_search",
      "input": { "query": "generative engine optimization GEO agency Chicago" },
      "sequence": 2
    }
  ]
}

One user query. Two retrieval events. Two separate source pools. Your content needs to be present across all of them.

The Real Model

Here's how most of the SEO community is currently thinking about this:

Rank. Get retrieved. Get cited.

Here's what's actually happening:

Be indexable. Be verifiable. Be extractable at the chunk level. Have fan-out coverage. Increase selection probability.

Those are not the same instructions.

Here's a realistic split: 70% of effective GEO is SEO. 20% is new tactical work around extractability and entity signals. And 10% is genuinely novel. AI visibility monitoring, citation tracking, scrubbing fan-outs, and earning brand mentions inside answers users actually trust.

GEOs who close that gap now won't need to scramble when it becomes obvious to everyone else.

Full article with selection signals, platform breakdown, and measurement guidance: zadroweb.com/blog/seo-vs-geo/

Move Over Python: PHP Is the Sleeping Giant of AI Agents

Dario Zadro — Wed, 29 Apr 2026 23:26:59 +0000

I've been coding in PHP for over 20 years. I've watched it get declared dead at least a dozen times. And every time, it just keeps running more of the internet.

So when AI started entering project needs, I didn't reach for Python. I didn't buy a seat in some workflow builder. I simply opened my existing codebase, wrote a service, and made an API call.

That's it. That was the whole unlock.

The Assumption Nobody Is Questioning

Python owns AI. Everybody knows this. If you're training models or building research pipelines, Python is the right tool. Not up for debate.

But here's the thing most teams aren't asking: are you actually training a model? Or are you calling an API?

Because those are wildly different problems. Most businesses building "AI features" today are doing the latter. They're sending a prompt to Claude, GPT, or Gemini and doing something useful with the response. That's a REST call. REST calls are language-agnostic. And PHP has been making REST calls since before most AI startups existed.

You Already Have the Stack

PHP powers over 71% of all websites with a known server-side language. Your CRM, your CMS, your admin panel -- already PHP. And AI agents at the production layer aren't exotic research software. They're authenticated API calls, database reads, webhook handlers, queue workers.

Here's something the AI industry won't tell you: most "agents" are just good old services. Strip away the marketing, and a typical AI agent is a class that accepts input, calls an external API, applies some logic, and returns output. We've been writing those since the early 2000s.

The agentic wrapper adds planning, memory, and tool-calling on top. Real, and it matters. But the underlying pattern is not foreign to anyone who has spent time in an MVC framework.

So why spin up a Python microservice to sit next to your PHP application, duplicate your data context across a process boundary, and introduce an entirely new runtime to maintain, just to make an HTTP request to an LLM?

The Overkill Problem

I've seen teams reach for AWS Bedrock to summarize a support ticket. I've seen n8n workflows with 14 nodes to do what is functionally a single API call. Make.com is a fantastic tool for connecting SaaS apps without code, but it is not the right answer for embedding an AI feature in a PHP application you already control.

A working Claude integration in PHP:

$client = new \GuzzleHttp\Client();

$response = $client->post('https://api.anthropic.com/v1/messages', [
    'headers' => [
        'x-api-key'         => $_ENV['ANTHROPIC_API_KEY'],
        'anthropic-version' => '2023-06-01',
        'content-type'      => 'application/json',
    ],
    'json' => [
        'model'      => 'claude-haiku-4-5-20251001',
        'max_tokens' => 1024,
        'messages'   => [
            ['role' => 'user', 'content' => $userPrompt]
        ],
    ],
]);

$data  = json_decode($response->getBody(), true);
$reply = $data['content'][0]['text'];

No platform. No monthly seat. No new infrastructure. Composer, Guzzle, an API key, and you're live.

What an Actual Agent Looks Like

An API call waits for a response and returns it. An agent decides what to do next, calls tools, checks its own output, and loops until the task is done. Here's that shift in PHP using Neuron AI:

namespace App\Neuron;

use NeuronAI\Agent\Agent;
use NeuronAI\Agent\SystemPrompt;
use NeuronAI\Chat\Messages\UserMessage;
use NeuronAI\Providers\AIProviderInterface;
use NeuronAI\Providers\Anthropic\Anthropic;
use NeuronAI\Tools\PropertyType;
use NeuronAI\Tools\Tool;
use NeuronAI\Tools\ToolProperty;

class FitnessAgent extends Agent
{
    protected function provider(): AIProviderInterface
    {
        return new Anthropic(
            key:   $_ENV['ANTHROPIC_API_KEY'],
            model: 'claude-haiku-4-5-20251001',
        );
    }

    protected function instructions(): string
    {
        return (string) new SystemPrompt(
            background: ['You are a knowledgeable fitness assistant.'],
            steps:      ['Use available tools to look up workout plans before answering questions about them.'],
            output:     ['Give clear, practical guidance based on the workout data returned.']
        );
    }

    protected function tools(): array
    {
        return [
            Tool::make('get_workout', 'Look up a workout plan by name or muscle group.')
                ->addProperty(
                    new ToolProperty(
                        name:        'workout_name',
                        type:        PropertyType::STRING,
                        description: 'The name or muscle group of the workout to retrieve.',
                        required:    true
                    )
                )
                ->setCallable(function (string $workout_name) {
                    $pdo  = new \PDO($_ENV['DB_DSN'], $_ENV['DB_USER'], $_ENV['DB_PASS']);
                    $stmt = $pdo->prepare("SELECT exercises, sets, reps FROM workouts WHERE name = ?");
                    $stmt->execute([$workout_name]);
                    $row  = $stmt->fetch(\PDO::FETCH_ASSOC);
                    return $row ? json_encode($row) : 'Workout not found.';
                }),
        ];
    }
}

$reply = FitnessAgent::make()
    ->chat(new UserMessage('How many sets should I do for a beginner chest workout?'))
    ->getMessage()
    ->getContent();

echo $reply;

The agent receives the question, decides it needs the get_workout tool, calls it with the extracted muscle group or plan name, and folds the result into its response. All without you wiring that logic manually. That's the shift from API wrapper to agent.

PHP's Territory

Python wins at model training, ML research, data science pipelines, and computer vision. Uncontested. Go use Python for that.

PHP's territory is the production web layer. CRMs, dashboards, ecommerce platforms, CMS systems, admin panels, business workflow tools. That layer is already PHP. The agents should be too.

Your agent needs access to your authenticated user session, your database schema, your business rules, your caching layer. Transferring all of that to an external Python service isn't just overhead. It's a technical debt liability.

You need an API key, a service class, and the PHP codebase you've probably already been running in production.

The giant was never asleep. Everyone else just has their eyes closed.

For the full breakdown including RAG in PHP, MCP, FrankenPHP, and the complete ecosystem rundown, read the full article at zadroweb.com.

Missing Database Indexes Are Killing Your Page Speed

Dario Zadro — Thu, 12 Mar 2026 15:54:21 +0000

I provide SEO. I also build apps. And the performance problem I see most often has nothing to do with meta tags, Core Web Vitals scores, or caching plugins.

It's missing database indexes.

Everyone chases the green scores. Images get lazy-loaded. Fonts get preloaded. Someone installs a caching plugin and calls it done. Green across the board. Screenshot posted on LinkedIn. Everybody claps.

But the uncached request still exists. The logged-in user still exists. The admin dashboard still exists. The report page pulling from six tables still exists. Caching hides the problem. It doesn't fix it.

The Fast Diagnostic

Enable MySQL's slow query log:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SHOW VARIABLES LIKE 'slow_query_log_file';

Reproduce the slow page. Check the log. Then run EXPLAIN on whatever shows up:

EXPLAIN
SELECT * FROM parent_table p
JOIN child_table c ON c.parent_id = p.id
WHERE p.account_id = 42 AND p.status = 1;

Four columns tell the whole story: type, key, rows, and Extra.

ALL in type with NULL in key is the thing you don't want to see. Especially inside a subquery running once per parent row. Not mysterious. Just waste.

The Fixes

Foreign key columns — index every column used in a JOIN:

ALTER TABLE child_table ADD INDEX idx_parent_id (parent_id);

Composite indexes — column order matters. Most-filtered column goes first:

ALTER TABLE parent_table
ADD INDEX idx_account_status_created (account_id, status, created_at);

JSON extractions — can't index a computed expression directly. Use a generated column:

ALTER TABLE event_log
ADD COLUMN event_source VARCHAR(100)
GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(payload, '$.source'))) VIRTUAL,
ADD INDEX idx_event_source (event_source);

Don't overdo it — every index slows writes. Index what you actually query. That's it.

WordPress Specifically

WordPress runs 42.5% of the web (W3Techs, March 2026). And wp_postmeta does not scale gracefully under plugin pressure. Don't even get me started on RankMath's database bloat.

The Index WP MySQL For Speed plugin by Ollie Jones is a solid first move for standard installs. Heavily customized sites need a manual EXPLAIN review.

Real Result

A dashboard recently: 3+ seconds to load, 120,000 records, correlated subqueries hitting unindexed join columns. Thousands of row reads per load, every single request.

Three index statements. Instant. Same server, same code, same database.

Check the DB structure before you blame the host or code. The answer is usually closer than you think.

Full breakdown on the Zadro Web blog: https://zadroweb.com/blog/database-indexes-slow-website/