DEV Community: Natalie Yevtushyna

SEO Used to End at the Click. AI Agents Are Changing That.

Natalie Yevtushyna — Wed, 12 Aug 2026 14:15:09 +0000

AI agents SEO isn't just "get found by AI systems" anymore. It's making sure a site has enough accurate commercial evidence and clear next steps that an agent can actually compare options, make a recommendation, and advance a transaction — not just cite you.

Discovery used to be the finish line. Now it's stage one.

Traditional SEO ends at the click: someone searches, picks a result, and you measure what happens from there. AI agents add real work between those steps — comparing specs, checking availability, filtering by price, filling out an RFQ, moving a cart toward checkout — often on the user's behalf, with the user reviewing before it commits.

A manufacturer can rank for a technical component query and still be commercially unusable to an agent if the page is missing material grade, MOQ, lead time, or certifications. Retrievable ≠ selectable.

This isn't speculative — the infrastructure is already live

Google shipped the Universal Commerce Protocol (UCP) in January 2026 — an open standard for agentic commerce, noted as compatible with AP2 (Agent Payments Protocol).
OpenAI connected product discovery to Instant Checkout via its Agentic Commerce Protocol.
ChatGPT started rolling out multi-product carousel ads in August 2026 — real brands, screenshot-verified placements, per Digiday and Search Engine Land.

Discovery, validation, and execution are becoming connected technical layers, not separate concerns.

One stat worth using carefully

Cloudflare data put automated traffic at ~57% of observed HTTP requests by mid-2026. That does not mean 57% of your visitors are shopping agents — that number includes training crawlers, monitoring, scrapers, and general bot traffic. The narrower, accurate takeaway: the discovery-relevant slice of that traffic is growing fast, but don't conflate it with buyer intent or transaction volume.

The framework: Retrieval → Validation → Execution

We expanded our existing two-gate model into three:

Retrieval — can the AI system find and confidently select you at all?
Validation — can it verify price, availability, credibility, and policy?
Execution — can it actually complete the action (checkout, RFQ, booking) without hitting a dead end?

Most SEO content still stops at Gate 1. Gate 3 — structured product data, feed accuracy, checkout accessibility — is where the real gap is right now, and where the opportunity is.

Full piece with sources: seeklab.io/blog/seo-used-to-end-at-the-click
Free audit: seeklab.io/audit

Building Aiden: a physical AI agent device that plugs into any phone/computer over USB and operates it like a human would. Go + C++ + Python stack, no API needed. https://github.com/AidenAI-IO/aiden-firmware, AMA on the architecture if curious.

Natalie Yevtushyna — Thu, 06 Aug 2026 07:22:08 +0000

GitHub - AidenAI-IO/aiden-firmware: AI Agent hardware for mobile phone · GitHub

AI Agent hardware for mobile phone. Contribute to AidenAI-IO/aiden-firmware development by creating an account on GitHub.

github.com

Why Good DTC Products Still Get Missed by AI Shopping Recommendations

Natalie Yevtushyna — Tue, 04 Aug 2026 07:01:39 +0000

There's no single tactic for getting a product into an AI "best of" roundup — because "AI roundup" isn't one channel. It can be a publisher's tested list, a shopping card in search results, a conversational comparison, a retailer's own listing, or a "recommended for you" module. Each of those pulls from different data, so optimizing one doesn't move the others.

Here's the model that's actually useful: treat every product as a record with five layers that all have to hold up at once.

1. Identity — what is it, specifically? "The Weekend Set" tells a system nothing. "Carry-on travel duffel with removable shoe compartment" does.

2. Evidence — dimensions, materials, ingredients, compatibility. Lifestyle copy isn't a substitute for specs a system (or a shopper) can compare.

3. Commercial facts — price and availability, and they need to match everywhere: product page, feed, checkout. A blue variant marked available on-page but out-of-stock in the feed creates uncertainty for humans and noise for machines.

4. Technical access — can crawlers actually see this? A variant selector that only exposes price and stock after a script fires is a common and avoidable failure mode.

5. Independent proof — authentic reviews, credible third-party coverage. Not bought placements — actual public evidence beyond the brand's own claims.

Google and OpenAI both publish documentation on how they ingest product data (Merchant Center, Manufacturer Center, ChatGPT's product feed spec) — but neither publishes a placement formula. Structured data isn't a ticket in; it's a way to make facts less ambiguous once they're already true on the page.

The most common failure isn't mysterious. It's usually one of: thin product pages with no real differentiators, JS-gated product details, feed data that disagrees with the live page, category pages that are just filter grids with no buying context, or products that are orphaned five clicks deep with no internal links pointing to them.

A practical fix sequence:

One governed source of product truth (name, SKU, price, availability, images — owned by someone, not scattered across three teams)
Audit flagship/high-margin product and category templates first, not every SKU
Upgrade product pages to decision-grade info (the actual spec a buyer needs to compare)
Build category and buyer-guide content that answers pre-brand research queries
Add authentic, product-specific reviews — not review volume for its own sake
Localize the actual offer (price, sizing, shipping, returns) — not just the copy

On measurement, don't chase a single "share of voice" number — AI shopping results shift by query wording, market, and account state. Track the controllable inputs instead: crawlability of priority pages, structured data validity, feed health, category coverage for non-branded queries, and internal linking depth. Keep a change log so you're not over-attributing a visibility bump to one fix when three things shipped that month.

Full breakdown (with the layer-by-layer consistency checklist) is on the SeekLab blog. If you want your own product pages, feeds, and structured data checked against this, SeekLab runs a free audit.

The Token Price on the Landing Page Isn't Your Real LLM Cost

Natalie Yevtushyna — Wed, 29 Jul 2026 16:56:38 +0000

Comparing LLM providers by the token price on their landing page is a bit like comparing phone plans by the advertised monthly rate before taxes, fees, and overage charges. Technically a number, not the number that ends up on your bill.

What the headline price usually hides

Output vs. input pricing — a lot of providers charge meaningfully more for output tokens than input. If your workload generates long responses (summaries, drafts, chat), output pricing dominates the actual bill, not the input rate that got top billing on the pricing page.
Gateway/platform fees — on top of the underlying model rate, some routing layers add their own fee, and it's not always obvious it's stacked on top rather than included.
Failed calls — a failed request doesn't refund itself in time. Retries, monitoring, and support tickets are real costs that never show up in a per-token comparison.
Search/context fees — anything doing retrieval or search-grounding (like Perplexity's Sonar) often bills extra for the search context on top of generation tokens.
Engineering time — every additional provider you integrate directly is SDK maintenance, another auth flow, another set of edge cases. That's a real cost even if it never shows up on an invoice.

The unit that actually matters: cost per completed task, not cost per token

If an agent workflow makes five model calls to complete one user-facing task, the number worth tracking is total cost for that task end-to-end, not the sticker price of whichever model handled step three. A "cheap" model that needs more retries or produces worse output that requires a second pass can end up costing more per completed task than a pricier model that gets it right the first time.

Practical version of this: route by task complexity, not by defaulting everything to one model.

classification / simple extraction  -> cheapest capable model
summarization / drafting            -> mid-tier model
final reasoning / code review       -> your strongest model

Escalate only the steps that actually need it. Sending every request through your best (and priciest) model because it's the one you're most confident in is the single fastest way to overspend.

Where a low-cost unified endpoint actually helps

If your workload is genuinely high-volume and mostly simple (classification, short-form generation, agent substeps), the pricing model of your routing layer matters more than usual. Something like GonkaRouter, which lists per-token pricing as low as $0.0004/1M tokens on an OpenAI-compatible endpoint, is worth knowing about specifically for that high-volume-simple-task tier, not necessarily as a wholesale replacement for whatever handles your hardest reasoning steps.

Same caveat applies to every pricing figure in this space, including that one: token prices move, sometimes tied to underlying compute cost. Check the live pricing page before you build a cost model around any specific number, including ones in this post.

The actual checklist before switching providers for cost reasons

[ ] Did you compare output pricing, not just input pricing?
[ ] Did you account for gateway/platform fees stacked on top of the base model rate?
[ ] Did you measure cost per completed task, not cost per raw API call?
[ ] Did you test real prompts, not just the benchmark examples on a comparison page?
[ ] Are you routing simple steps to cheap models and reserving your best model for the steps that actually need it?

Curious what routing strategies people here have found actually move the needle, task-complexity-based routing, or is most of the savings coming from prompt compression and caching instead?

AI Model Router vs AI Gateway vs Inference Cloud: What's the Actual Difference?

Natalie Yevtushyna — Wed, 29 Jul 2026 16:55:09 +0000

"AI gateway," "model router," "inference cloud," and "AI platform" get used interchangeably in a lot of marketing copy, which makes evaluating any specific product harder than it needs to be. They're not the same thing, and knowing which category something actually falls into tells you what to expect before you read a single feature list.

The four categories, roughly

Category	What it actually is	Example shape
Consumer AI app	A ready-made chat interface for talking to a model	ChatGPT, Claude.ai
Inference cloud	Broad infra: deployment, GPUs, fine-tuning, hosting your own models	Together AI, Replicate
AI gateway	Enterprise-facing control layer: routing + policy + governance + observability across providers	Portkey, Kong AI Gateway
Model router	Developer-facing: one API, multiple models, minimal ceremony	OpenRouter, GonkaRouter

The line between "gateway" and "router" is genuinely blurry in practice, a lot of products are both. But the useful distinction is intent: a gateway usually markets itself on governance and policy controls for platform teams, a router markets itself on developer speed, get one endpoint working against multiple models fast.

Where this actually matters: picking the right tool for the job

You need	Reach for
A/B testing models for a specific agent step	A router, not a full gateway
Org-wide policy enforcement, PII masking, audit logs across teams	A gateway, not just a router
Deploying and fine-tuning your own model weights	An inference cloud, neither of the above
Just talking to a model in a UI	A consumer app, you don't need an API layer at all

Picking the wrong category wastes time. Adopting a governance-heavy gateway when you just want to A/B test two models for one agent step adds ceremony you don't need yet. Adopting a lightweight router when you actually need org-wide policy enforcement means you'll outgrow it and migrate later.

GonkaRouter as a worked example of the "router" category

GonkaRouter is a clean example of the developer-first router shape: one OpenAI- and Anthropic-compatible endpoint, currently routing to Qwen, Kimi, and MiniMax model families, built on the Gonka decentralized compute network. It's explicitly not positioning itself as an inference cloud (it doesn't host your custom model weights) or a governance-heavy gateway (no enterprise policy engine mentioned), it's the "get one endpoint working against several models, fast" category.

Use-case fit, concretely:

Use case	Fits a router like this?
Agent steps needing different models (planning vs. summarization)	Yes, this is the core case
A/B testing model quality for one feature	Yes
Enterprise-wide policy enforcement across many teams	No, that's gateway territory
Hosting your own fine-tuned model	No, that's inference-cloud territory
Just prototyping, no real traffic yet	Yes, especially with a trial credit to test before committing

Getting started, if the fit is right

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://api.gonkarouter.io/v1",
)

response = client.chat.completions.create(
    model="Qwen/Qwen3-235B-A22B-Instruct-2507-FP8",
    messages=[{"role": "user", "content": "Hello!"}],
)

If you're OpenAI-client-shaped already, that's the entire integration. Current model list and live pricing: gonkarouter.io/models.

Curious how others here draw the router-vs-gateway line in practice, is it purely about governance features, or does self-hosted vs. hosted matter more to how you'd categorize a given tool?

OpenAI-Compatible" Means Format Compatible, Not Official Model Access

Natalie Yevtushyna — Wed, 29 Jul 2026 16:53:53 +0000

Every AI gateway's landing page says "OpenAI-compatible" somewhere near the top. It's become close to meaningless as a marketing phrase, because it's true of almost everything in this category, and it's also frequently misread as something it isn't.

What "compatible" actually means

It means: the request and response shape matches OpenAI's (or Anthropic's) API. Same JSON structure, same auth header pattern, same client library works with a base_url swap. It does not mean:

You're getting OpenAI's or Anthropic's actual models
Behavior is identical to calling OpenAI or Anthropic directly
Every parameter, every edge case, every streaming quirk is preserved

GonkaRouter is refreshingly direct about this distinction in its own materials, worth quoting because it's the right way to phrase it: "GonkaRouter's OpenAI-compatible API format does not mean official OpenAI model access. Its Anthropic-compatible API access does not mean official Anthropic model access." That's the sentence every gateway should have somewhere, and a lot of them don't say it this plainly.

Why this distinction is the thing to actually check

If your integration testing only confirms "the client library didn't throw an error," you've verified format compatibility, not behavioral compatibility. The gap between those two shows up in exactly the places that are annoying to debug after the fact:

Streaming behavior (does it chunk the same way?)
Tool/function calling schema strictness
How system prompts get weighted or truncated
Error format on rate limits or invalid requests
Context window handling at the edges

None of this means "compatible" gateways are bad, it means the compatibility claim is about the interface, and you still need to test the actual model behavior against your specific workload before trusting it in production.

Currently supported models (worth checking against your own needs, not this post)

GonkaRouter's current lineup, per their own docs: MiniMax-M2.7, Kimi-K2.6, and GLM-5.2. Model lists in this space move fast and I've seen slightly different lineups mentioned across their own posts (some mention Qwen instead of GLM), so treat any specific model list, including this one, as a snapshot, not a guarantee, check gonkarouter.io/models directly before you build against a specific model ID.

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://api.gonkarouter.io/v1",
)

response = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M2.7",
    messages=[{"role": "user", "content": "Hello!"}],
)

The honest evaluation checklist

[ ] Confirmed the format matches (client library works without errors)
[ ] Tested actual model behavior against your real prompts, not just a hello-world call
[ ] Checked streaming behavior specifically if your app depends on it
[ ] Verified error format for the failure modes you actually care about (rate limits, invalid input)
[ ] Didn't assume "compatible" means "identical to the provider it's compatible with"

Has anyone run into a compatibility gap that only showed up after real production traffic, not initial testing? Curious what category it fell into, streaming, tool calling, or something else entirely.

A Repeatable Way to Actually Compare Models Through a Gateway (Not Vibes)

Natalie Yevtushyna — Wed, 29 Jul 2026 16:52:28 +0000

"We tried a few models and this one felt better" is how most model selection actually happens, and it's not a great methodology. Once you've got a gateway giving you access to multiple models through one endpoint, the actual hard part isn't the integration, it's building a comparison that isn't just vibes.

A methodology that isn't vibes

Define the task category first. "Chatbot response" and "agent planning step" and "code generation" are different evaluation problems, don't lump them into one test.
Write 10-20 representative prompts per category. Pull from real usage if you have any, not just hello-world examples.
Run the identical prompt set against every model you're comparing. Same prompts, same order, logged consistently.
Score on the dimensions that actually matter for that task, not a generic "quality" score:

Test type	What to actually measure
Basic chat	Relevance, tone, completeness
Structured output	JSON/table formatting reliability, not just "looks right"
Agent step	Planning quality, tool-output interpretation
Code prompt	Correctness (run it), formatting, explanation clarity
Long prompt	Instruction retention across the full context, not just the first paragraph
Cost	Tokens per completed task, not per call
Latency	User-facing response time, including any retry overhead
Error handling	Does your app's retry/fallback logic actually trigger correctly

Pick per-task, not one model for everything. The model that wins on chat quality isn't necessarily the one you want for structured extraction.

The production checklist that's easy to skip after step 5

Getting a model comparison right and then skipping basic production hygiene is a common failure mode:

[ ] Keys in environment variables or a secrets manager, never in frontend code
[ ] Logging model name + latency per request (you'll need this when something's slow and you don't know why)
[ ] Token usage tracked by prompt category, not just aggregate spend
[ ] Retries with backoff for transient errors, not naive infinite retry
[ ] Reviewed the provider's data-handling policy before sending anything sensitive through it

Where a gateway actually helps this process

The value of something like GonkaRouter here isn't "one more model to try", it's that the comparison methodology above becomes cheap to run because you're not standing up N separate SDK integrations just to get the test data. One endpoint, swap the model parameter, run the same prompt set. Current lineup per their docs: MiniMax-M2.7, Kimi-K2.6, GLM-5.2, worth checking gonkarouter.io/models directly since model lists in this category shift often.

from openai import OpenAI

client = OpenAI(api_key="sk-xxxxxx", base_url="https://api.gonkarouter.io/v1")

for model in ["MiniMaxAI/MiniMax-M2.7", "moonshotai/Kimi-K2.6"]:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": PROMPT}],
    )
    log_result(model, response)

Being honest about scope: this is a router for a specific, currently small model set, not a universal catalog. If your roadmap needs a much broader model list, that's worth checking against their current docs before committing, not assuming it'll grow to cover you.

What's your actual eval loop look like, do you score outputs manually, or has anyone gotten a decent automated grading step working for this kind of comparison?

Evaluating an OpenAI-Compatible Router? Here's What Actually Differs Between Them

Natalie Yevtushyna — Tue, 28 Jul 2026 07:28:34 +0000

"OpenAI-compatible" shows up on basically every model router's landing page now, so it's stopped being a useful differentiator on its own. The more useful comparison is what's actually different underneath: pricing model, which models are genuinely well-supported versus just listed, and what the onboarding friction looks like before you've committed any real integration time.

GonkaRouter is one router in this space worth breaking down as a case study for what to actually check, since its own positioning makes the comparison explicit.

Direct integration vs. a router, the actual tradeoffs

	Direct multi-provider integration	Router (e.g. GonkaRouter)
API keys	One per provider	One
Endpoints	One per provider	One
Request/response format	Different per provider	Normalized to one format
Billing	Separate per provider	Consolidated
Model switching	Code changes, new adapters	Change a model name
Failure isolation	You handle it per provider	Depends entirely on the router's own uptime

That last row is the one worth sitting with. A router removes N integration paths and replaces them with one dependency that now sits in front of all your traffic. If the router goes down, you don't have five providers failing independently, you have one failure point affecting everything routed through it. That's a real tradeoff, not just an upside, and it's worth asking any router directly what their own uptime and incident history look like before routing production traffic through them.

What GonkaRouter specifically claims

One OpenAI-compatible endpoint, currently listing Kimi, Qwen, and MiniMax model families
Built on the Gonka Network, described as distributed GPU infrastructure rather than a single centralized inference stack
Token pricing listed as low as $0.0004 / 1M tokens, with pricing explicitly noted to move with network utilization, not a flat rate
No monthly subscription, pay-as-you-go
Email login with a one-time 20 USDT trial credit for testing before you commit

The "is this an OpenRouter alternative" question

GonkaRouter's own materials frame this as a category comparison rather than a feature-for-feature claim, which is the right way to think about it. Both sit in the "AI gateway" category (unified access to multiple models), but the actual differentiators are Gonka Network as the backing infrastructure, the specific pricing structure, and which models are supported, not one being a strict superset of the other.

If you're evaluating a router in this category, the questions worth asking regardless of which one you're looking at:

Which models are supported today, not on a roadmap
Is pricing flat or does it move with underlying infra load, and how is that communicated
What does the free/trial tier actually let you test before you're paying
What's the router's own reliability track record, since it's now a single point of failure for everything routed through it

Getting a first request working

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://api.gonkarouter.io/v1",
)

response = client.chat.completions.create(
    model="moonshotai/Kimi-K2.6",
    messages=[{"role": "user", "content": "Hello!"}],
)

If your app is already on an OpenAI-shaped client, that's the entire integration, no rewrite of orchestration or retry logic.

Current models and live pricing: gonkarouter.io/models. Docs: gonkarouter.io/docs.

Has anyone here actually load-tested one of these decentralized-compute-backed routers against a centralized one? Curious whether the "distributed GPU network" framing shows up as latency variance in practice, that's the part I'd want to see real numbers on before trusting it with anything latency-sensitive.

LLM Failover Isn't Just a Backup Model: Retry, Fallback, Cache, and Semantic Routing

Natalie Yevtushyna — Tue, 28 Jul 2026 07:07:00 +0000

"Just add a fallback model" is the kind of advice that sounds complete until you've actually shipped it. A single backup model handles one failure mode (the primary is down) and quietly ignores the other four that show up in production: slow responses, malformed output, rate limits, and a fallback model that doesn't accept the same context shape as your primary.

Here's the pattern breakdown that actually holds up.

The five patterns, and when each one is the right call

Pattern	What it does	Best for	Main risk
Retry	Same model, again, after a delay	Timeouts, brief 5xx, short rate-limit windows	Too many retries just adds latency
Fallback routing	Different model or endpoint	Primary is down or unhealthy	Output can differ meaningfully from the primary
Load balancing	Spreads traffic across healthy paths	High-volume traffic	Behavior varies slightly by which path you land on
Caching	Reuses a prior response	Repeated FAQs, deterministic tasks	Stale or wrong cache hits if governance is loose
Semantic routing	Routes by meaning/intent, not just a static model name	Agents, multi-domain apps	Misclassification routes the request badly

None of these replace the others. A production system usually needs some combination: check cache, check model health, classify the request, pick a route, validate the output, log the decision. Skip the validation step and you'll eventually route a mangled response straight into a downstream tool call.

The part that actually bites: model context

This is the failure mode that doesn't show up until you've already shipped the "add a fallback" version. Model context, meaning system prompt, conversation history, retrieved documents, tool schemas, output format rules, isn't guaranteed to survive a switch between models cleanly. Things that quietly differ:

Context length limits
How system prompts get interpreted
Tool/function schema expectations
JSON formatting strictness
Streaming behavior

OpenAI-style and Anthropic-style APIs use genuinely different request shapes (OpenAI reference, Anthropic Messages API). An "OpenAI-compatible" gateway smooths over the request/response format, it does not guarantee the fallback model behaves the same way given the same input. That distinction matters and is easy to skip past when you're just trying to get failover shipped.

For agents specifically, this compounds

A single user task can trigger planning, tool selection, summarization, and a final response, each a separate model call. If any one of those fails without a sane retry or fallback path, the whole task can collapse. Worth building in from the start:

Retry limits with backoff and jitter (not unlimited retries)
Short fallback chains, long chains just add latency without adding reliability
Health checks tracking timeouts, 5xx, and 429 patterns specifically
Output validation before anything downstream (a tool call, a database write) touches the response
Logging per route: which model, latency, token usage, whether a fallback fired

Where a router fits into this

An AI gateway or model router centralizes the routing/retry/cache logic instead of every service reimplementing its own version. GonkaRouter is one example, an OpenAI- and Anthropic-compatible endpoint currently routing to MiniMax-M2.7, Kimi-K2.6, and GLM-5.2, built on the Gonka decentralized compute network. Worth being precise here: "compatible" means the request/response format matches, not that every model behaves identically to what you'd get from OpenAI or Anthropic directly, that distinction is exactly the model-context problem above, and no gateway makes it disappear on its own.

If you're evaluating something like this, the actual test is: change only the endpoint in an existing integration, run real prompts through each supported model, and measure latency, output quality, and failure behavior before you decide where your app-level retry and fallback logic needs to live.

Quick checklist before shipping failover

[ ] Defined behavior for timeout, 5xx, 429, and invalid JSON, not just "the request failed"
[ ] Retry limits with backoff, not unbounded retries
[ ] Fallback chains kept short
[ ] Context transformation handled explicitly between models, not assumed
[ ] Caching scoped with real invalidation rules, not just "cache everything"
[ ] Every route logged: model, latency, tokens, fallback fired or not
[ ] Output validated before it reaches a tool call or downstream write

Curious what others here are using for the context-transformation step specifically, that's the part I've seen bite people hardest when a fallback model quietly handles system prompts differently than the primary.

GonkaRouter: One OpenAI/Anthropic-Compatible Endpoint for Qwen, Kimi, and MiniMax

Natalie Yevtushyna — Tue, 28 Jul 2026 06:55:39 +0000

If your app already talks to OpenAI or Anthropic in their native request format, adding a second or third model provider usually means a second SDK, a second auth flow, and a second set of edge cases to handle when that provider has a bad day. That's the specific problem GonkaRouter is built around: one OpenAI- and Anthropic-compatible endpoint in front of multiple models, so you're not maintaining N integrations for N providers.

The migration pattern is endpoint-first, not rewrite-first

The part worth calling out for anyone evaluating this kind of router: GonkaRouter doesn't ask you to change your code structure, just three things:

Swap the API endpoint
Use a GonkaRouter API key
Pick a supported model name

If your app is already built against the OpenAI or Anthropic client shape, your orchestration logic, retry handling, and conversation state all stay exactly as they are. That's the difference between "add a provider" and "rebuild the integration layer," and it's why endpoint-first migration is worth checking for before you commit to any router.

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxx",
    base_url="https://api.gonkarouter.io/v1",
)

response = client.chat.completions.create(
    model="moonshotai/Kimi-K2.6",
    messages=[{"role": "user", "content": "Hello!"}],
)

What's actually behind the endpoint

GonkaRouter runs on the Gonka decentralized AI compute network rather than a single centralized inference stack, and routes to Qwen, Kimi, and MiniMax model families (examples given: Qwen3-235B-A22B-Instruct, Kimi-K2.6, MiniMax-M2.7). For a multi-step agent, that's genuinely useful: planning, summarization, and final-response generation don't all need the same model, and testing that without a router usually means wiring up three separate provider clients just to compare.

Where this fits in practice:

Agent pipelines — route planning, tool-selection, and summarization steps to whichever model handles each best, without three separate SDKs.
Chatbots — one endpoint for conversational traffic, swap models to compare cost and quality.
Backend workloads — centralize credentials and model access instead of every internal service holding its own provider keys.

Pricing and access

Per GonkaRouter's own pricing page, token pricing is listed as low as $0.0004 / 1M tokens, and new accounts get a one-time 20 USDT trial credit after email login, enough to run real prompts before wiring it into anything production-facing. Pricing and model availability are the kind of thing that shifts, so check the live pricing page rather than trusting a number in any article, including this one.

One thing worth being direct about, since it's easy to gloss over: this sits in front of your API traffic, so it can see the requests going through it. GonkaRouter's privacy policy states usage may be logged for performance monitoring and abuse prevention, worth a read if you're routing anything sensitive or regulated through it.

Worth checking if

You're already on an OpenAI- or Anthropic-shaped client and want another model family without a rewrite
You want to A/B test Qwen, Kimi, or MiniMax against your current model for a specific step, not your whole pipeline
You want one place to hold model credentials instead of scattered per-service API keys

Full writeup and the models list: gonkarouter.io, docs at gonkarouter.io/docs.

Curious if anyone here has compared Gonka-network-routed inference against a more centralized router on latency or reliability, that's the part I'd want real numbers on before committing production traffic.

How to Optimize robots.txt for AI Crawlers in 2026

Natalie Yevtushyna — Sun, 19 Jul 2026 19:14:03 +0000

The most common robots.txt mistake I see in 2026 is treating "AI bots" as a single group and blocking all of them with one rule. That decision quietly costs you discoverability in AI answer engines while doing nothing to stop the scrapers you actually care about.

AI crawler robots.txt optimization requires selective crawler permissions that protect proprietary content while keeping revenue-critical pages accessible to search engines and AI answer systems. Before you touch a single directive, separate AI training crawlers, AI answer/search crawlers, user-triggered fetchers, traditional search crawlers, commercial SEO crawlers, and unknown scrapers. They serve different purposes, and blocking the wrong one is where the damage happens.

robots.txt is a crawl-permission file, not a security tool

/robots.txt is a public crawler-permissions file that tells compliant crawlers which URL paths they may request. It does not secure private content, remove indexed pages, or force non-compliant scrapers to obey anything.

The file lives at the root of the host. For https://www.example.com/, that's https://www.example.com/robots.txt. Rules apply per host and protocol, so subdomains, ccTLDs, and staging hosts each need their own validation. The formal spec is RFC 9309.

The four core directives:

Directive	Function	Practical rule
`User-agent`	Identifies the crawler group	Use official user-agent tokens only
`Disallow`	Blocks crawling for matching paths	Low-value, duplicate, private-looking, or training-restricted areas
`Allow`	Permits crawling for matching paths	Exceptions inside broader blocked folders
`Sitemap`	Points to XML sitemaps	Product, blog, language, and image sitemap discovery

One distinction that trips people up constantly: crawling control is not indexing control. A blocked URL can still appear in search results if other pages link to it. If you want to prevent indexing, you need noindex in a meta robots tag or HTTP header — and the crawler has to be allowed to fetch the page to see it. Block the URL in robots.txt and the noindex never gets read.

And for anything genuinely sensitive — login areas, staging, pricing files, partner docs — robots.txt is the wrong layer entirely. It's public. Listing /private-pricing/ just tells people where to look. Use auth, IP restrictions, signed URLs, or WAF rules. MDN is blunt about this: robots.txt is not security.

Classify the crawler before you write the rule

A single vendor often runs separate agents for training, search retrieval, user-triggered access, and infrastructure. Blocking the wrong one reduces discoverability without solving content reuse.

Category	Purpose	robots.txt implication	Warning
Search indexing	Traditional search discovery	Usually allow for public pages	Blocking Googlebot/Bingbot damages SEO
AI training	Model training	Allow or block by content policy	Blocking doesn't undo prior collection
AI answer/search	Retrieval, citation, answer discovery	Often allow for public pages	Blocking cuts AI-era discoverability
User-triggered fetchers	Fetch a URL a user requested	Treat separately	May not apply robots.txt the same way
Commercial SEO	Audits, link analysis	Allow/block/rate-limit as needed	Affects third-party diagnostics
Unknown scrapers	Unverified bots	Don't rely on robots.txt	Use CDN/WAF, rate limits, logs

Here's the current user-agent landscape — but verify these against official docs before deploying, because tokens and roles change:

Org	Token	Category	Policy note
OpenAI	`GPTBot`	AI training	Block if training reuse isn't acceptable
OpenAI	`OAI-SearchBot`	AI answer/search	Allow if ChatGPT search visibility matters
OpenAI	`ChatGPT-User`	User-triggered	Don't treat like GPTBot without checking
Google	`Googlebot`	Search indexing	Keep unblocked unless there's a precise reason
Google	`Google-Extended`	Generative AI token	Google says it does not affect Search ranking
Bing	`bingbot`	Search indexing	Keep unblocked if Bing matters
Perplexity	`PerplexityBot`	AI answer/search	Perplexity recommends allowing it
Perplexity	`Perplexity-User`	User-triggered	User-requested, not governed like normal crawling
Apple	`Applebot`	Search/assistant	Apple ecosystem discovery
Apple	`Applebot-Extended`	AI training control	Search access without foundation-model training
Meta	`Meta-ExternalAgent`	AI/product	Verify casing and purpose
Common Crawl	`CCBot`	Public web corpus	Blocking reduces dataset inclusion

A quick note on Anthropic: crawler names like ClaudeBot, Claude-User, and Claude-SearchBot show up in reporting and transparency materials, but verify the current docs directly before shipping production rules. Don't paste unverified user-agent snippets from old blog posts — that's how stale rules propagate.

Google-Extended deserves special care: it's a robots.txt product token, not an HTTP request user-agent. Do not block Googlebot when you only meant to restrict Google's generative-AI product use.

Allow, block, and partial access

Selective access is the sane default for public commercial sites: keep search + answer/search crawlers on public pages, block specific training crawlers only when you have a real licensing, legal, or content-reuse reason.

Maximum discovery (public brand site):

User-agent: *
Allow: /
Sitemap: https://www.example.com/sitemap.xml

Block training crawlers, allow everything else:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: *
Allow: /

Allow AI answer access but not broad training access:

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: GPTBot
Disallow: /

Ecommerce parameter/crawl-waste control:

Disallow: /cart/
Disallow: /checkout/
Disallow: /*?sort=
Disallow: /*?filter=

Multilingual site — keep language folders and sitemaps open:

Allow: /en/
Allow: /de/
Allow: /fr/
Allow: /zh/
Allow: /ar/
Sitemap: https://www.example.com/sitemap-index.xml

One warning on the ecommerce pattern: blocking every query string can nuke filtered landing pages that match real search demand and convert. Check search data before blanket-blocking parameters.

And never use a production robots.txt as a staging control. A public staging URL returning 200 leaks through links, screenshots, and cached assets no matter what Disallow: / says. Password-protect it.

The eight mistakes that actually cause damage

Disallow: / in the wrong user-agent group — the catastrophic one. Blocks Googlebot/Bingbot/Applebot from the whole site. Keep groups clean, avoid duplicate User-agent: * blocks.
Treating all AI crawlers as one — blocking GPTBot ≠ blocking OAI-SearchBot; blocking Google-Extended ≠ blocking Googlebot.
Blocking language folders — kills international discoverability on /de/, /zh/, /ar/, etc.
Blocking CSS/JS needed for rendering — blocked resources create incomplete page understanding; answer/search crawlers may render differently than Googlebot.
Using robots.txt to hide sensitive content — it's public; you're advertising the folder.
Letting the CDN override the origin file — Cloudflare's managed robots.txt can change what's served. Always fetch the live file from the public domain.
Relying on Crawl-delay — Google's Googlebot ignores it. Use server-side rate limiting or CDN controls for load.
Blocking PDFs without checking value — datasheets, certifications, and compliance docs often drive qualified B2B inquiries.

Audit it log-first

Don't copy a blocklist before you know which crawlers actually hit your site. The workflow:

Export raw server logs — user-agent, IP, timestamp, URL, status code, bytes, response time, host/protocol.
Group known crawlers by the categories above.
Verify IPs where official methods exist — user-agent strings are trivially spoofed. Perplexity and OpenAI publish verification info; Perplexity offers JSON IP endpoints.
Map crawled URLs to business value — which pages actually matter vs. filters/carts/staging.
Check status codes — fix 5xx for important crawlers, investigate accidental 403s to search/answer bots, clean 404s, reduce redirect chains.
Reconcile robots.txt with sitemaps — sitemaps should list canonical, indexable, 200 URLs; never list blocked URLs.
Validate internal linking — key pages shouldn't depend on JS click events or orphaned sitemap inclusion.
Review multilingual coverage — confirm hreflang targets are crawlable and canonicals don't collapse every language back to English.
Check CDN/WAF rules — confirm the CDN serves the intended file and isn't blocking good crawlers via data-center IP rules.
Keep a rollback file — save the previous version, test on staging, deploy in a low-risk window, monitor 48 hours.

Run this monthly or after any major site change, and recheck tokens after provider updates. A file that was correct last quarter drifts out of date fast.

FAQ

Should I block AI crawlers in robots.txt?
For most public commercial sites, no. Allow search indexing and answer/search crawlers on public pages, restrict low-value paths, and block specific training crawlers only when you have a clear content-control, licensing, or legal reason.

Does robots.txt stop AI from using my content?
Only partially. Disallow asks compliant crawlers not to fetch a path. It doesn't undo already-collected data, bind non-compliant scrapers, or remove content learned from other sources.

What's the difference between GPTBot and OAI-SearchBot?
GPTBot is OpenAI's training crawler; OAI-SearchBot supports ChatGPT search discovery. Many sites block the former for training reuse while allowing the latter for visibility. Verify current behavior in OpenAI's docs.

Does blocking Google-Extended hurt Google rankings?
Google says Google-Extended controls generative-AI product use and does not affect Search inclusion or ranking. The real risk is confusing it with Googlebot.

Is robots.txt enough to protect private content?
No. It's public. Sensitive paths need authentication, IP restrictions, signed URLs, or WAF/CDN controls.

*Originally published on SeekLab.io. If you want a practical review of your own robots.txt, crawler access, JS rendering, and sitemap/internal-link setup, SeekLab has a free audit.

How to Get Your Products Recommended by ChatGPT Shopping: The 2026 E-commerce GEO Guide

Natalie Yevtushyna — Tue, 07 Jul 2026 22:04:31 +0000

ChatGPT Shopping GEO helps e-commerce brands improve product discovery in ChatGPT by making their product pages crawlable, structured, accurate, comparable, and trustworthy. The goal is not to "hack" ChatGPT or force a recommendation. The goal is to make your official website, catalog, product data, and buying information clear enough that ChatGPT-like shopping systems, search engines, and real buyers can understand what you sell and why it fits a specific shopping prompt.

A practical ChatGPT Shopping GEO guide starts with the parts that affect discovery before content volume: robots.txt access, OAI-SearchBot permissions, indexable product pages, rendered product data, Product and Offer schema, accurate price and availability, clear shipping and return policies, useful category content, internal links, multilingual structure, and buyer trust signals. For independent stores, official brand websites, exporters, B2B catalogs, and cross-border e-commerce sites, these are the areas most likely to affect shopping search visibility and lead quality.

OpenAI has confirmed that ChatGPT Shopping Research can create personalized buyer guides, ask clarifying questions, and compare products. OpenAI has also stated that product results are organic and unsponsored, and that Instant Checkout does not give products ranking preference. That means the safest approach is disciplined AI shopping optimization: fix the discovery foundation first, label uncertain ranking claims carefully, and prioritize the products that matter commercially.

Why a ChatGPT Shopping GEO guide starts with crawlable, trustworthy product data

A product cannot be recommended, compared, or cited reliably if the page is blocked, incomplete, duplicated, or showing stale product data. Many e-commerce teams want to start with new content, but the first gate is simpler: can a crawler access the product page, understand the key product facts, and follow links to related products or categories?

OpenAI's crawler documentation says OAI-SearchBot is used for ChatGPT search features. If a site opts out of OAI-SearchBot, OpenAI says it will not be shown in ChatGPT search answers, though it may still appear as a navigational link. That makes robots.txt a commercial visibility decision, not just a developer setting.

Google's guidance for optimizing websites for generative AI features on Google Search also starts with normal Search requirements: crawlability, index eligibility, helpful content, images, page experience, and clear product information. This matters because generative shopping experiences still depend on accessible, understandable web and merchant data.

For product discovery in ChatGPT, the practical implication is direct: do not start with speculative AI shopping tricks while your key product pages are noindex, buried behind filters, blocked by robots.txt, or missing visible price and stock information.

Foundation area	What to check first	Common failure	Commercial impact
Crawling	robots.txt, OAI-SearchBot, server status, blocked folders	Product or category paths disallowed after migration	Product pages may not be discoverable
Indexing	noindex tags, X-Robots-Tag, canonical URLs	Product templates inherit noindex from filtered pages	Search and AI-driven discovery potential drops
Rendering	Product title, price, stock, links, schema in rendered HTML	Data loads through blocked API calls or late JavaScript	Machines may see a thin or incomplete page
Product data	Title, SKU, GTIN, MPN, price, currency, availability	Page, schema, feed, and checkout show different values	Buyer trust and machine confidence decline
Trust	Reviews, policies, official seller proof, support details	Official store looks weaker than reseller pages	AI-assisted buyers may choose clearer sources

For a deeper technical review, SeekLab.io's technical SEO audit checklist is useful when teams need to inspect crawling, indexing, Core Web Vitals, schema, JavaScript rendering, internal links, sitemap.xml, and robots.txt together instead of treating each issue separately.

What the ChatGPT Shopping GEO guide can and cannot promise

A credible ChatGPT shopping guide must separate confirmed platform facts from practical SEO and GEO inferences. OpenAI has not published a full ChatGPT Shopping ranking algorithm. Any vendor or consultant claiming a guaranteed formula for ChatGPT product recommendations is overpromising.

Here is what is confirmed by official sources:

Confirmed point	Source	Practical meaning
ChatGPT Shopping Research can create personalized buyer guides and ask clarifying questions	OpenAI Shopping Research	Product and category pages should answer real buying constraints, not just list specs
Shopping Research may make mistakes about price and availability	OpenAI Shopping Research	Price, stock, shipping, and return data must be kept current
Instant Checkout supports purchases from supported merchants and is built around the Agentic Commerce Protocol	OpenAI Instant Checkout	Commerce workflows are moving closer to AI-assisted buying
Product results are organic and unsponsored	OpenAI Instant Checkout	ChatGPT Shopping should not be described as paid placement based on current public information
Instant Checkout items are not preferred in product results	OpenAI Instant Checkout	Checkout integration is not a ranking shortcut
When ranking multiple merchants selling the same product, ChatGPT may consider availability, price, quality, primary seller status, and Instant Checkout enablement	OpenAI Instant Checkout	Official brand websites should clearly prove seller status and keep merchant data accurate

The practical inferences are still important, but they should be worded carefully. Product schema may help machines understand your catalog, but OpenAI has not confirmed it as a direct ChatGPT Shopping ranking factor. Reviews may improve trust and product understanding, but exact weighting is not public. External mentions may support brand confidence, but they should be earned through legitimate product information, not manipulated citations.

A safer way to think about a generative engine optimization guide is this: GEO extends traditional SEO, structured data, feed hygiene, entity clarity, and conversion content into AI-assisted discovery scenarios. It does not replace SEO. A store with weak canonical logic, incomplete product data, and thin category pages does not become AI-ready by adding a few keywords to product descriptions.

GEO, SEO, and shopping feed optimization are connected but not identical

Discipline	Main job	Typical assets	Limitation
Product SEO	Help product and category pages rank in search	Titles, descriptions, category pages, internal links, schema	Rankings do not guarantee AI shopping recommendations
Shopping feed optimization	Make product data eligible and competitive in merchant platforms	Feed attributes, product IDs, price, availability, images	Feeds may not explain use cases, trust, or official brand authority
ChatGPT Shopping GEO	Help AI systems discover, interpret, compare, and trust products	Crawlable pages, schema, product data, guides, reviews, policies, entity clarity	Platform logic is partly opaque and may change

This distinction matters for budget decisions. A team should not buy complex monitoring software before fixing blocked product pages, stale prices, missing Offer schema, or product grids with no decision-support content. The work that improves AI shopping optimization is often the same work that makes the website more useful for buyers.

The ChatGPT Shopping GEO guide framework for product discoverability

The best sequence is not "publish more pages." It is "make the right products discoverable, understandable, and commercially convincing." For many independent stores and official company websites, 20 well-structured priority products will do more for shopping search visibility than 500 weak pages with inconsistent data.

flowchart TD
    A["Confirm crawl and index eligibility"] --> B["Clean product and category architecture"]
    B --> C["Standardize product data and schema"]
    C --> D["Improve product and category content clarity"]
    D --> E["Build trust and citation-ready information"]
    E --> F["Strengthen internal links"]
    F --> G["Localize multilingual and cross-border signals"]
    G --> H["Monitor AI-driven discovery and referrals"]
    H --> I["Prioritize by business impact"]
    I --> A

1. Confirm crawl and index eligibility

Start with the revenue pages: priority categories, best-selling products, high-margin SKUs, product families, and RFQ pages. Check robots.txt, OAI-SearchBot access, noindex tags, canonical URLs, HTTP status codes, XML sitemaps, and crawl depth.

A common e-commerce failure is a product page that looks fine in the browser but is noindex, canonicalized to the wrong URL, missing from the sitemap, or only accessible through internal search. That page is functionally weak for product discovery in ChatGPT because machines may not treat it as a reliable product source.

2. Clean product and category architecture

Category architecture tells machines how products relate to each other. Thin grids, faceted crawl traps, duplicated variants, and orphan products make the catalog harder to interpret.

For example, a category such as "industrial pumps" should not only display products. It should clarify pump types, use cases, materials, capacity ranges, compatibility, and selection criteria. That content helps both AI systems and buyers compare options.

SeekLab.io often approaches this through full-site crawling and structured analysis, not isolated page checks. The point is not to fix everything. The point is to identify which architecture issues are suppressing growth and which can be deprioritized.

3. Standardize product data and schema

Google's product structured data documentation explains how Product markup can support rich product information such as price, availability, ratings, shipping, and returns. Schema.org also defines relevant vocabulary for Product, Offer, Review, AggregateRating, and MerchantReturnPolicy.

For ChatGPT Shopping GEO, structured data should be treated as a clarity layer. It helps machines parse what is already visible on the page. It should not contradict the page, hide information, or mark up reviews that users cannot see.

Product data field	Why it matters	Practical rule
Product name	Core matching signal for shopping prompts	Include product type, model, key attribute, and use case where natural
Brand	Helps entity understanding	Use one consistent brand name across page, schema, feed, and Organization data
SKU, GTIN, MPN	Reduces ambiguity across merchants and markets	Publish identifiers where useful and commercially safe
Price and currency	Supports comparison and trust	Keep page, schema, feed, and checkout aligned
Availability	OpenAI names availability in merchant comparison context	Do not mark sold-out products as in stock
Images	Supports product understanding and rich results	Use clean product images and valid image URLs in schema
Shipping and returns	Reduces buying uncertainty	Show visible policies and add structured data where appropriate
Reviews and ratings	Supports trust and product evaluation	Mark up only authentic, visible, eligible reviews

Teams that need implementation support can review SeekLab.io's work around schema data compliance, especially where Product, Offer, Organization, Breadcrumb, FAQ, and Review markup need to be validated at template level.

4. Improve product and category content clarity

ChatGPT Shopping Research is designed for comparisons, constraints, and trade-offs. That means thin product descriptions are a weak asset. A buyer may ask for "best carry-on backpack for a 3-day business trip," "manufacturer of corrosion-resistant fasteners for marine use," or "official store for replacement filters available in Germany." A generic product page does not answer those prompts.

Useful product content usually includes the primary use case and target buyer, key specifications in plain language, compatibility and variant guidance, comparison with related products in the catalog, official seller confirmation, and answers to common pre-purchase questions.

SeekLab.io's GEO content strategy covers how to structure product and category content so that AI systems can extract the right information for shopping prompts, comparison tasks, and buyer guides.

5. Build trust and citation-ready information

Trust signals matter because AI shopping systems are designed to recommend products that buyers can rely on. An official brand website that looks weaker than reseller pages, lacks visible policies, or has no contact information is a weaker source for AI-assisted buying recommendations.

Useful trust elements include visible and structured return and shipping policies, authentic and marked-up customer reviews, official seller confirmation through Organization schema and About pages, clear contact and support information, secure checkout signals, and consistent brand identity across the website and schema.

6. Strengthen internal links

Internal links help machines understand how products, categories, guides, and policies connect. A product page that is not linked from any category, related product, or guide may be treated as an orphan even if it is indexed.

Useful internal link patterns include category-to-product links for all priority SKUs, product-to-related-product links within families, guide-to-product links from buyer guides and comparison content, and policy links from product and checkout pages.

7. Localize multilingual and cross-border signals

For cross-border e-commerce, exporter websites, and B2B catalogs serving multiple markets, language and regional signals affect both search and AI discovery. Hreflang tags, localized product data, market-specific pricing, and regional shipping and return policies help machines match products to buyers in the right market.

8. Monitor AI-driven discovery and referrals

Standard analytics may not capture AI-driven referrals well. Referral traffic from ChatGPT, Perplexity, Gemini, and other AI platforms may appear as direct traffic, unattributed referrals, or under platform-specific hostnames. Monitoring requires checking referral sources, tracking mentions in AI outputs, and testing key shopping prompts directly in AI platforms.

SeekLab.io's AI citation monitoring approach covers how to track AI-driven referrals, test product visibility in shopping prompts, and identify gaps between search rankings and AI recommendation patterns.

ChatGPT Shopping GEO FAQs

What is ChatGPT Shopping GEO?

ChatGPT Shopping GEO is the practice of optimizing e-commerce product pages, product data, schema, content, and trust signals so that AI shopping systems such as ChatGPT Shopping Research can discover, understand, compare, and recommend products more reliably.

Does ChatGPT Shopping use paid placements?

OpenAI has stated that product results in ChatGPT Shopping Research are organic and unsponsored. Instant Checkout integration does not give products ranking preference based on current public information.

What does OAI-SearchBot do?

OAI-SearchBot is OpenAI's crawler for ChatGPT search features. If a website blocks OAI-SearchBot in robots.txt, OpenAI says it will not appear in ChatGPT search answers, though it may still appear as a navigational link.

Is product schema required for ChatGPT Shopping?

OpenAI has not confirmed product schema as a direct ChatGPT Shopping ranking factor. However, structured data helps machines parse product information more reliably. It should be treated as a clarity layer that supports discovery, not a guaranteed ranking signal.

What is the difference between GEO and SEO for e-commerce?

Product SEO focuses on ranking in search engines. Shopping feed optimization focuses on merchant platform eligibility. ChatGPT Shopping GEO focuses on making products discoverable, interpretable, and trustworthy for AI-assisted shopping systems. The three disciplines overlap but serve different discovery channels.

How long does ChatGPT Shopping GEO take to show results?

Results depend on crawl frequency, product data quality, content improvements, and platform changes. Fixing critical crawl and indexing issues can have faster effects. Content and trust improvements typically take longer. AI platform behavior is partly opaque and subject to change.

Where can I learn more about GEO for e-commerce?

SeekLab.io publishes practical GEO guides, case studies, and monitoring approaches at seeklab.io. The free site audit tool is a useful starting point for identifying crawl, indexing, schema, and content issues that affect both search and AI discovery.