DEV Community: Juan Camilo Auriti

YouTube is the #1 cited domain in Google AI Overviews. Reddit is #2. Your blog is nowhere.

Juan Camilo Auriti — Tue, 13 Oct 2026 07:00:00 +0000

Ahrefs published the most comprehensive ranking of domains cited in Google AI Overviews in September 2026. They tracked every domain AI Overviews cited across over 3 million US queries using their Brand Radar tool, then ranked them by mention share.

The top 10:

#	Domain	Mention share	Pages cited
1	youtube.com	22.9%	1,737,252
2	reddit.com	18.5%	830,641
3	facebook.com	10.1%	514,175
4	google.com	8.8%	1,220,228
5	instagram.com	5.6%	277,245
6	quora.com	4.7%	171,198
7	en.wikipedia.org	4.0%	88,400
8	tiktok.com	3.3%	140,750
9	amazon.com	3.3%	148,116
10	walmart.com	1.0%	47,425

The top 5 domains account for 65.9% of all AI Overview citations. The top 10 account for 82.2%.

Look at what is not on that list. No tech blog. No SEO publication. No developer documentation site. No content marketing hub. The domains that AI Overviews cite most are user-generated content platforms, social media, e-commerce, and Wikipedia.

Why YouTube dominates

YouTube is the single most-cited domain, with 22.9% of all citations and 1.7 million distinct pages cited. A separate Ahrefs analysis found that among AIO citations that did not rank in Google's top 100 for the same keyword, 18.2% were YouTube URLs. YouTube is getting cited even when it does not rank organically for the query.

This makes sense when you understand how AI Overviews work. Google's documentation describes query fan-out: the model splits the original query into related sub-queries and retrieves pages for each. Video content surfaces for sub-queries where text results are thin. "How to" queries, product demonstrations, and visual tutorials trigger video results that traditional text content cannot serve.

YouTube also has a structural advantage. Every video page has a structured description, timestamps, transcript data, and metadata that Google's own systems can parse cleanly. The content is already segmented into chapters. It is, in effect, pre-chunked by creators who do not think of themselves as doing content chunking.

Reddit as the second pillar

Reddit captures 18.5% of citations with 830,641 pages cited. The WashU study (55,393 queries, presented at the October 2026 ACM Internet Measurement Conference) noted that AI Overviews rely less heavily on user-generated content than traditional first-page results, but Reddit's position in the Ahrefs data suggests UGC is still a massive citation source in absolute terms.

Reddit's advantage is freshness and specificity. A Reddit thread about "best laptop for video editing under $1000" contains multiple first-hand opinions, specific model numbers, and trade-off discussions that a generic buyer's guide cannot match. Google's AI guide explicitly calls for "first-hand" content and "unique points of view." Reddit is the largest repository of first-hand experience on the internet.

What this means if you produce written content

The implication is not "stop writing and start making YouTube videos." It is that the competitive landscape for AI citations is different from the landscape for organic search.

In organic search, you compete against other pages targeting the same keyword. In AI Overviews, you compete against every format that answers any related sub-query the fan-out process generates. A blog post about "how to set up Supabase auth" is not just competing with other blog posts. It is competing with a YouTube tutorial, a Reddit thread, and a Stack Overflow answer.

The content that still gets cited from written sources tends to share specific properties:

Original data and analysis. The WashU study found that AIO-cited domains score higher on credibility than average first-page results. Sites that publish original research, proprietary data, or expert analysis get cited because the AI cannot synthesize that information from commodity content. This is what Google means by "non-commodity content."

First-hand experience. Google's guide says it explicitly: "a first-hand review provides a unique point of view." If you have used a tool, built a project, or debugged a specific problem, that experience is not replicable by AI. It gets cited.

Specificity over breadth. The CXL study showed that 55% of AI Overview citations come from the first 30% of a page. Pages that front-load a specific, well-defined answer get cited. Pages that build up to a general conclusion do not.

The uncomfortable part

If you are a content marketer, the data says your competition is not other content marketers. It is a 19-year-old posting a phone recording on TikTok, a Reddit user writing a 200-word comment at 2am, and a Wikipedia editor who has maintained the same article for a decade.

These sources get cited because they are specific, first-hand, and non-commodity. They are not optimized. They are not structured for AI. They are just real.

The GEO playbook that tells you to add llms.txt and Schema markup is optimizing the wrong layer. The layer that matters is whether your content contains something that cannot be generated by the AI doing the citing. If it can, the AI already has the answer and has no reason to cite you.

If it cannot, you do not need llms.txt. You need to publish it.

55% of AI Overview citations come from the first 30% of your page. Here's the data.

Juan Camilo Auriti — Sun, 11 Oct 2026 07:00:00 +0000

Most SEO advice tells you to write a compelling introduction, build up to your main point, and deliver the answer after you have set the context. Two independent citation studies say the opposite: if your answer is not in the first 30% of the page, there is a better than even chance it is not getting cited by AI search engines at all.

The CXL study: 100 AI Overview citations

CXL analyzed 100 Google AI Overview citations to see where on the source page the cited passage actually appeared. They mapped each citation to its position relative to the full page length.

The results:

55% of cited passages appeared within the first 30% of the source page.
The 10-20% zone alone produced more citations than any other segment.
The top 20% of pages accounted for 48 of 100 citations.
The bottom 40% of pages accounted for only 21.

The concentration is not subtle. If your core answer lives at the 50% mark because you built up to it with context and storytelling, it sits in a part of the page that produced fewer citations in this sample than the first 10%.

The Kevin Indig dataset: 18,012 ChatGPT citations

Kevin Indig ran a larger analysis across 1.2 million search results and 18,012 verified ChatGPT citations. The pattern was the same:

44.2% of ChatGPT citations came from the first 30% of the document.
After the first third, citation likelihood drops sharply.
Indig described it as a "ski ramp" effect: a steep cliff after the first 30%, then a long, slow tail.

Two different AI systems (Google AI Overviews and ChatGPT), two different datasets (100 citations and 18,012 citations), same shape. The retrieval step that feeds both systems appears to weight content position in a way that rewards front-loading.

Why this happens

Google's own documentation explains the mechanism. AI Overviews use query fan-out: the model splits the original query into multiple related sub-queries, retrieves pages for each, and assembles a response from the results. The retrieval step has a context budget. When a page is fetched, the model reads from the top. If the answer is buried at 60%, it may not make it into the context window before the budget is spent.

This is the same reason the CXL study found that FAQ sections can still get cited from deep page positions: each FAQ question-and-answer pair is structurally self-contained, so the model can extract a complete answer without needing the surrounding context. But for narrative content, position matters.

What the Ahrefs data adds

The Ahrefs analysis of 863,000 keywords and 4 million AI Overview URLs found that only 38% of cited pages appeared in the organic top 10 for the same query, down from 76% in July 2025. A separate BrightEdge analysis put the number at 17%.

This means most cited pages do not rank for the exact keyword being searched. They rank for related sub-queries generated by fan-out. Your page does not need to hold the top position for the primary keyword to get cited. It needs to contain a clear answer to a related question, and that answer needs to be near the top of the page.

Practical changes

If you write technical content, blog posts, or documentation, the implication is straightforward:

Put the answer first, context second. If your article is about a specific problem, the clearest statement of the solution should appear in the first 20% of the page. Not after the third subheading, not after you have warmed the reader up.

Front-load definitions. If your page defines a concept, the definition should be in the first paragraph or two. The CXL data shows the 10-20% zone is the single most productive segment for citations.

Keep FAQ sections for specific questions. FAQ blocks can still get cited from deep positions because each answer is self-contained. This is the one structural pattern that survives the position effect.

Measure with Search Console. Google introduced dedicated Search Generative AI performance reports in June 2026, rolled out worldwide by August 31. You can now track AI Overview impressions directly rather than relying on third-party tools.

What this does not mean

Front-loading is not the same as dumbing down. The data says the answer should be early, not that the page should be short. The bottom 40% of pages still produced 21 of 100 citations in the CXL study. Context, examples, and depth still matter for readers who click through. But the AI retrieval step that decides whether you get cited appears to read from the top and stop when it has enough.

The pages that win in AI search are the ones where the first thing a human reader finds is also the first thing a retrieval system extracts. If you have been writing introductions that delay the answer, the citation data says to stop.

Google's mythbusting guide says stop obsessing over Schema. The data agrees.

Juan Camilo Auriti — Sat, 10 Oct 2026 07:00:00 +0000

When Google published its official guide on optimizing for generative AI features in Search in May 2026, it included a mythbusting section. The kind of section that upsets people who sell the things it busts.

Here is what Google explicitly lists under things you do not need:

You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in generative AI search.

That covers llms.txt. But the guide goes further. It says standard technical SEO is what counts for AI features, and that no special schema, no special markup, and no special files are required beyond what Google has always recommended.

The GEO agency playbook, meanwhile, still leads with three items: add llms.txt, add more Schema.org markup, and implement "content chunking" for AI retrieval. Let me check each one against the data.

llms.txt: the file 97% of sites publish for nothing

I covered this in detail in the first part of this series. The short version: Ahrefs analyzed 137,210 domains and found that 97% of llms.txt files received zero requests in May 2026. SE Ranking analyzed 300,000 domains and found no correlation between having the file and being cited by AI. Limy tracked 515 million AI bot events and counted 408 requests to llms.txt. Removing the variable from their machine learning model improved prediction accuracy.

Google's John Mueller compared llms.txt to the keywords meta tag. The keywords meta tag is the canonical example of a self-declared signal that search engines learned to ignore because every site claimed to be the best one. The same logic applies here: a file where you describe your own site as important is not a signal any serious retrieval system would trust.

Schema.org: necessary, but not the lever GEO agencies sell

Google's guide is careful here. It does not say Schema is useless. It says you do not need additional or special schema for AI features. Standard structured data that helps Google understand your content continues to matter. What does not matter is the layer of AI-specific Schema that some agencies add to their deliverables.

The evidence backs this up. The WashU study presented at the October 2026 ACM Internet Measurement Conference analyzed 55,393 searches and 61,212 citations. They found that 29.8% of cited domains did not appear in the first-page results at all, which means Google's AI source selection uses a pool distinct from its ranking algorithm. If Schema were the primary lever for AI citation, you would expect the most-marked-up pages to dominate. They do not.

What the WashU study did find is that AIO-cited domains received higher average credibility scores than traditional first-page results. Credibility, in this context, is not about Schema. It is about source quality, domain authority, and content substance. Google's own guide reinforces this: the most important factor is "valuable, non-commodity content" with a "unique point of view."

The Ahrefs analysis of 863,000 keywords and 4 million AI Overview URLs found that only 38% of cited pages appeared in the organic top 10 for the same query, down from 76% in their July 2025 study. A separate BrightEdge analysis put the number at 17%. If Schema markup were the deciding factor, the overlap with top-ranking pages (which typically have the most Schema) would be higher, not lower.

Chunking: the tactic with no public evidence

"Content chunking" for AI retrieval is the idea that you should break your content into self-contained semantic units so an LLM can ingest them individually. It sounds plausible. It has no public evidence behind it.

I searched for peer-reviewed studies, large-scale analyses, or even practitioner log data showing that chunked content gets cited more frequently than unchunked content. I found none. What I found instead is the CXL 100-citation study, which showed that 55% of AI Overview citations come from the first 30% of a page. Kevin Indig's analysis of 18,012 verified ChatGPT citations found the same pattern: 44.2% from the first 30%, dropping sharply after.

That is not chunking. That is front-loading. The data says put your answer near the top, not split your content into pieces. Google's guide does not mention chunking at all, which is consistent with the absence of evidence for it.

What the data says actually works

The peer-reviewed GEO paper by Aggarwal et al. (KDD 2024) is the closest thing this field has to a landmark study. They built a benchmark (GEO-Bench) and measured what happens to page visibility when you edit the page itself. The methods that worked:

Adding citations to credible sources within your content
Adding statistics
Adding quotations from authoritative sources
Improving content density and specificity

These are content-level edits, not file-level or markup-level changes. Their benchmark showed visibility boosts of up to 40% in generative engine responses. That is an effect size. llms.txt, extra Schema, and chunking have no published effect size.

Google's guide and the independent data converge on the same conclusion. The work that matters for AI search visibility is the work that has always mattered for search: make content that is original, specific, and useful. The tactics that agencies package as "GEO-specific" are either things you should already be doing (basic Schema, crawlability, semantic HTML) or things with no measured effect (llms.txt, chunking, AI-specific markup).

What this means for your audit

I run geo-optimizer-skill, and we deliberately do not score sites on llms.txt presence, Schema count, or chunking. We score on the signals that have evidence: crawlability, content density, semantic structure, and whether your pages render for bots that do not execute JavaScript.

If your GEO audit leads with llms.txt and Schema density, you are optimizing the easy-to-instrument metrics, not the outcome metrics. The easy ones produce diffs and look like work. The outcome metric (does your content get cited by AI) requires an experiment, not a dashboard.

That is the trap. The same trap as tuning alert thresholds instead of asking whether the alert should exist. The metric that is easy to measure is rarely the one that describes the result.

Google said llms.txt does nothing. I checked what 137,210 domains actually got.

Juan Camilo Auriti — Fri, 09 Oct 2026 07:00:00 +0000

The llms.txt file was supposed to be the bridge between your website and AI search engines. A markdown file at your root, a curated list of your best pages, a clean map for models that struggle with bloated HTML. Add it, and ChatGPT, Perplexity, and Google AI Overviews would finally find you.

I wanted to believe it. I built an open-source GEO audit tool that checks for llms.txt among its signals. Then the data came in, and it doesn't say what the checklist articles say.

What Google said

In May 2026, Google published its official guide on optimizing for generative AI features in Search. The guide has a mythbusting section. This is what it says about llms.txt and similar files:

You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in generative AI search.

Google's John Mueller had been saying it for over a year before it landed in the documentation. In April 2025, answering a question on Reddit, he put it plainly:

"AFAIK none of the AI services have said they're using LLMs.TXT (and you can tell when you look at your server logs that they don't even check for it). To me, it's comparable to the keywords meta tag — this is what a site-owner claims their site is about … (Is the site really like that? well, you can check it. At that point, why not just check the site directly?)"

The keywords meta tag. The canonical example of a signal search engines learned to ignore because every site claimed to be the best one.

What Google did next

Ten days before the Search guide told everyone to stop bothering, Google's Chrome team shipped an llms.txt check inside Lighthouse as part of its experimental Agentic Browsing audits. The documentation, last updated May 5, 2026, says:

Without this file, agents may spend more time crawling the site to understand its high-level structure and primary content.

Two teams inside the same company, pointing in opposite directions. When pressed on the contradiction, Mueller framed it as: llms.txt is "not done for search." He called it a "temporary crutch, perhaps to save some tokens" for AI coding tools parsing developer documentation. Not something non-developer sites need.

So which is it? I went to the data.

Study 1: Ahrefs, 137,210 domains

Ahrefs published the largest access study to date on June 15, 2026. They looked at every domain in Ahrefs Web Analytics that received traffic in May 2026 and checked each root for an llms.txt file returning HTTP 200.

The numbers:

28% of the 137,210 domains publish an llms.txt file (about 38,000 sites).
97% of those files received zero traffic in May 2026. Nothing fetched them at all. Not AI bots, not generic crawlers, not humans.
96% of the requests that did reach llms.txt files came from bots.
19.5% of those bot fetches came from named AI tools. GPTBot was first, Claude-Code second. Both are training crawlers and coding agents, not answer engines.
Zero requests came from AI bots for llms.txt files that didn't exist. AI bots never go looking.

That last point is the one that kills the mental model where a model "checks for" your file before answering a question about you. It doesn't. It fetches whatever URLs its retrieval step already surfaced, which is normally your HTML.

Ahrefs also found something unsettling: the largest single research crawler in the dataset identified itself as prompt-injection-survey/1.0. Someone is systematically studying llms.txt as a prompt injection vector, because AI agents are designed to ingest and trust whatever the file says.

Study 2: SE Ranking, 300,000 domains

SE Ranking ran a separate analysis of nearly 300,000 domains. They tested whether having an llms.txt file correlates with how often a domain gets cited by AI systems.

It doesn't.

They used both statistical correlation (Spearman) and machine learning (XGBoost with SHAP analysis). The result: removing the llms.txt variable from the model improved its prediction accuracy. The file wasn't a weak signal. It was noise.

Adoption was 10.13% across their dataset, roughly 1 in 10 sites. No major AI platform has publicly committed to reading it.

Study 3: OtterlyAI, 90-day server log experiment

OtterlyAI ran a controlled experiment over 90 days. They placed a correctly implemented llms.txt file at the root of a test website and monitored AI bot traffic.

62,100+ total AI bot visits to the site over 90 days.
84 of those visits targeted /llms.txt.
That's 0.1% of AI bot traffic.
The site's average content page received ~265 AI bot visits in the same window. The dedicated AI file performed 3x worse than a random page.

They also noted that llms.txt "hardly performed better than an average .pdf file." AI crawlers don't treat it as privileged content.

OtterlyAI subsequently removed the llms.txt checker from their GEO audit tool, because the data showed its impact on AI crawler behavior is "marginal at best."

Study 4: Limy, 515 million bot events

Limy's analysis is the largest dataset I've seen on this question. They monitored 515,382,577 AI bot traffic events over a 90-day window across the brands they track.

408 requests targeted /llms.txt directly.
Out of 515 million.
That's 0.00008% of total AI crawler traffic.

Their word for the share was "statistically negligible." The bots that matter for AI search visibility (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended) overwhelmingly skip the file and crawl HTML directly.

What actually works (according to the same studies)

The studies don't say "do nothing." They say "do something different."

Google's own guide is clear about what matters: create valuable, non-commodity content. If an AI can write your article on its own, it will never cite you. It already has the answer. The guide points to first-hand experience, unique data, and original analysis as the signals that make content worth surfacing.

The Ahrefs study points out that the bots fetching llms.txt are coding agents reading developer documentation. If your site is API docs or SDK reference, a clean llms.txt genuinely helps. If your site is a blog, an ecommerce store, or a landing page, no agent is parsing your pages for fun. The file points at an empty room.

What moves the needle, according to the peer-reviewed GEO paper by Aggarwal et al. (KDD 2024), is content-level edits: adding citations to credible sources, adding statistics, adding quotations. Their benchmark showed these methods can boost visibility in generative engine responses by up to 40%. That is an effect size. llms.txt has no measured effect size.

What I did with my own tool

I maintain geo-optimizer-skill, an open-source Answer Engine Optimization audit tool with over 1,000 stars on GitHub. It checks for llms.txt among its signals, and I'm keeping the check.

But I changed what the check means. It doesn't score your site higher for having the file. It flags the file as present and moves on. The signals that actually affect your score are the ones with evidence behind them: crawlability, semantic structure, content density, citation-worthy passages, and whether your pages render for bots that don't execute JavaScript.

llms.txt is a 20-minute, zero-risk bet. Ship it if you want. But don't put it on your roadmap as a ranking play, don't pay anyone to "optimize" it, and don't let it displace the work that actually has evidence behind it.

The bottom line

Four independent studies covering 137,210 domains, 300,000 domains, 62,100 bot visits, and 515 million bot events all say the same thing. Google's official documentation says the same thing. John Mueller said the same thing over a year ago.

llms.txt is not an AI visibility tactic. It's a developer documentation tool that got mis-sold as an SEO tool. The disappointment around it traces back to that single category error.

If someone is selling you llms.txt as an AI-visibility tactic, the evidence isn't on their side.

I deployed the fix, restarted, saw nothing, and reverted a change that worked

Juan Camilo Auriti — Thu, 08 Oct 2026 11:00:00 +0000

A notification wasn't firing. I found the cause, wrote a small fix, deployed it, restarted the service, triggered the condition, and watched.

Nothing.

So I concluded the fix was wrong, reverted it, and went looking for a different cause. I spent most of a day on the different cause. There wasn't one.

The suppression

The notifier had a deduplication window:

DEDUP_WINDOW = timedelta(minutes=5)

def should_send(key: str, now: datetime) -> bool:
    last = store.get(key)
    if last and now - last < DEDUP_WINDOW:
        return False          # same alert, too soon
    store.set(key, now)
    return True

Entirely reasonable. It exists so a flapping condition doesn't send forty emails.

But the dedup key survived the restart — it was in shared storage, deliberately, so a restart couldn't be used to bypass suppression. Which means: my pre-fix test run had already registered the key. Then I deployed, restarted, and re-triggered within the same five minutes.

The fix ran. It computed the right decision. And then the dedup layer, correctly, declined to send a duplicate.

Both layers behaved exactly as designed, and the composition of the two produced a result identical to the bug I was trying to fix.

Why I believed the wrong thing

The observable I was checking — "did a notification arrive" — is downstream of the suppression. It cannot distinguish these three states:

the fix didn't work
the fix worked and the send was suppressed
the fix worked and the send failed for an unrelated reason

I read one silent outcome as one specific cause, because that's the cause I was already thinking about. Reverting was the worst possible move: it removed the correct change and left the key in place, so my next test after the revert was also inside a window, which confirmed my wrong conclusion a second time.

Two consistent negative results, both artifacts of my own test cadence.

What to check instead

Log the suppression, at the point of suppression. If the only trace of a dedup hit is the absence of an email, the layer is invisible during exactly the situations where it matters most.

def should_send(key: str, now: datetime) -> bool:
    last = store.get(key)
    if last and now - last < DEDUP_WINDOW:
        log.info("suppressed", key=key, age_s=(now - last).total_seconds(),
                 window_s=DEDUP_WINDOW.total_seconds())
        return False
    store.set(key, now)
    return True

One line. It turns my whole wasted day into a log entry that says suppressed key=... age_s=42 window_s=300.

Assert on the decision, not the delivery. The unit under test is "did the notifier decide to send", which is a function you can call. Whether an email arrived is a different question involving four more systems. I had been testing the wrong end of the pipeline because it was the end I could see.

Clear the key, or use a fresh one, when verifying a deploy. Either drop the dedup entry as part of the verification procedure, or trigger with a key that's never been used. Not by shortening the window in production — that changes the behaviour of the thing you're testing.

The general shape

Every idempotency and rate-limiting layer converts a real event into no event. That's the feature. The cost is that "nothing happened" stops being evidence of anything the moment one of those layers sits between you and your observable.

Anywhere you have dedup, debounce, rate limits, at-most-once delivery, or cache-on-negative, post-deploy verification has to either bypass the layer or read a signal from before it. Otherwise the layer will occasionally hand you a confident false negative, and a false negative that arrives twice in a row is extremely convincing.

The tell I now watch for: I got the same negative result twice, quickly. Fast repetition is the condition every suppression layer is built to detect. If two attempts a few minutes apart both showed nothing, the second one is not a confirmation — it's the most likely one to have been swallowed.

Reverting a change because you couldn't see its effect is the failure mode I actually want to name here. Not seeing an effect and having no effect are different findings, and only one of them justifies a revert.

Dependabot was watching 2 of my 6 updatable surfaces, and the config looked complete

Juan Camilo Auriti — Wed, 07 Oct 2026 11:00:00 +0000

My dependabot.yml, which I'd have described as done:

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule: { interval: "weekly" }
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule: { interval: "weekly" }

Python dependencies, GitHub Actions. It's a Python project with CI. Looks complete.

I ran an inventory of everything in the repo that a bot could update:

./pyproject.toml
./frontend/package.json
./integrations/astro-geoready/package.json
./Dockerfile
./Dockerfile.web
./action.yml
./.github/actions/geo-audit/action.yml
./.github/workflows/*.yml   (6 files)

Six distinct surfaces. Two covered.

What was missing, and why each was easy to miss

frontend/package.json — npm, not in the config at all. Dependabot is per-directory, and there was no npm entry anywhere. A whole frontend of dependencies, unwatched. This is the one I'd defend least: I just never added it.

integrations/astro-geoready/package.json — a second npm surface. Adding one npm entry for /frontend wouldn't have caught this. Every directory needs its own entry, and this one is a subpackage I forgot existed while writing the config for the one I was thinking about.

Dockerfile and Dockerfile.web — no docker ecosystem entry. Base image tags never get bumped. Both live in the root, so one entry covers them — but zero entries covered either.

.github/actions/geo-audit/action.yml — the interesting one. My github-actions entry with directory: "/" covers .github/workflows/ and the root action.yml. It does not cover a composite action nested in its own subdirectory. That file pins third-party actions, same as any workflow, and it was outside the watched set while sitting inside .github/, which is precisely why I'd assumed it was covered.

The audit command

Run this in any repo and compare the two lists by eye:

# every updatable surface
find . \( -path ./node_modules -o -path ./.venv -o -path ./dist \) -prune -o \
  \( -name 'package.json' -o -name 'requirements*.txt' -o -name 'pyproject.toml' \
     -o -name 'Gemfile' -o -name 'go.mod' -o -name 'Cargo.toml' \
     -o -name 'Dockerfile*' -o -name 'action.yml' -o -name 'action.yaml' \) -print | sort

# what dependabot is told to watch
grep -E 'package-ecosystem|directory' .github/dependabot.yml

Two commands, and the gap is the answer. The -prune matters: without it node_modules buries the signal under thousands of vendored package.json files.

The mapping, so you can read one list against the other:

file found	ecosystem	`directory`
`pyproject.toml`, `requirements*.txt`	`pip`	dir containing it
`package.json`	`npm`	dir containing it
`Dockerfile*`	`docker`	dir containing it
`.github/workflows/*`	`github-actions`	`/`
nested `action.yml`	`github-actions`	the action's own dir

That last row is the one nobody writes down.

The other half: a skipped PR doesn't come back

While fixing the config I found stale PRs from months earlier and closed a few as superseded — a patch bump that a later minor had already overtaken.

Dependabot does not reopen a PR you closed, and does not re-propose a version you rejected. Closing "the old one" tells it you've decided about that update. If the newer PR isn't actually open, that dependency now sits at its current version indefinitely, with no open PR and no error.

So: close superseded PRs only after confirming the superseding one exists and is open. And if you closed a batch during a cleanup, dependabot.yml won't tell you — the only signal is a dependency that stopped producing PRs, which looks exactly like a dependency that's up to date.

Why it looked complete

Because dependabot.yml describes what you asked for, and nothing anywhere describes what you should have asked for. There's no warning for an unwatched manifest. Adding an ecosystem is opt-in per directory, and the file reads as finished the moment it covers the ecosystems you were thinking about when you wrote it.

The generalisation: an allow-list has no error state. Reviewing it will always tell you it's correct — it lists exactly what it lists. The only way to audit one is from the outside, against the set it's supposed to cover.

Which is the same reason the audit above is two commands instead of one. One command reads the config. The second is the only one that can disagree with it.

input type="url" rejects the URL before your normalizer ever runs

Juan Camilo Auriti — Sun, 04 Oct 2026 11:00:00 +0000

I had a normalizer I was pleased with. Trims, lowercases the host, drops www., adds https:// when the scheme is missing, strips a trailing slash. Handles example.com, EXAMPLE.com/, www.example.com/about/.

Users typing example.com got a browser tooltip instead:

Please enter a URL.

The normalizer never ran. Not "ran and failed" — never executed, not once, for that input.

Why

<input type="url" name="site" required>

type="url" attaches native constraint validation, and the spec's definition of a valid URL requires a scheme. example.com has no scheme, so the input is invalid, so the form's implicit validation fails on submit — before the submit event handler where my normalizer lived.

The ordering is the whole bug. Native validation runs first. Your JavaScript is downstream of a gate that already rejected the input.

And a bare domain is exactly what people type. Nobody types https://. So the single most common input hit a wall built into the platform, and the code written to handle it sat there looking correct.

Three fixes, in the order I'd try them

1. Normalize before validation happens, not on submit.

Keep type="url" and its keyboard and its native messaging, but fix the value while the user is still in the field:

const input = document.querySelector('input[name="site"]')

input.addEventListener("blur", () => {
  const v = input.value.trim()
  if (v && !/^[a-z][a-z0-9+.-]*:\/\//i.test(v)) {
    input.value = "https://" + v
  }
})

blur and not input: rewriting the value on every keystroke fights the person typing, and moves the caret out from under them. On blur they've finished.

This is my default. It's four lines, it keeps every native behaviour, and by the time validation runs the value is valid.

2. Drop type="url", keep the keyboard, own the validation.

<input type="text" inputmode="url" autocomplete="url"
       name="site" required
       aria-describedby="site-hint">
<p id="site-hint">A domain or full URL, e.g. example.com</p>

inputmode="url" still gets the URL-friendly keyboard on mobile, which is most of what type="url" was buying you. You now own validation, which means you own the error message too — and you must actually render one, because you just removed the browser's.

3. Keep type="url" and replace the message with setCustomValidity.

Worth knowing, but it doesn't solve this: it changes the wording of the rejection, not the rejection. Use it when the input genuinely is invalid, not to work around a value you could have fixed.

Don't fix it by deleting the validation

The tempting fourth option is novalidate on the form, or type="text" with nothing replacing it. Both make the symptom disappear.

If you do that, you owe the user everything you removed: an error message tied to the field with aria-describedby, aria-invalid="true" when it's wrong, focus moved to the first bad field on failed submit, and a message that says what to do rather than what went wrong. The native behaviour was doing all of that for free, including for screen readers.

That's the reason fix 1 is my default: it changes when the value is corrected and leaves the platform's accessibility work alone.

Check every surface, not the one in the bug report

This is the part I actually got wrong. I fixed the field named in the report and shipped.

There were three. The main audit form, a second form on a landing page, and a query parameter that skipped the form entirely and went straight to the API — which had its own validation and its own opinion about schemes.

A normalizer is only as consistent as its least-covered entry point, and entry points multiply quietly. Enumerate them:

grep -rn 'type="url"' --include='*.astro' --include='*.html' --include='*.tsx' --include='*.jsx' .

Then the ones without a form at all: query params, deep links, API bodies, a CLI flag, anything pasted from an email. Each is a place a bare domain can arrive.

The rule: normalize at the boundary where a string becomes your data, not at the boundary where a form is submitted. One is a single function every path routes through. The other is however many forms you have, minus the ones you forgot.

Which is the same rule as the trailing slash, arriving from the other side. Same function, in fact — the one that has to prepend the scheme before urlsplit gets a chance to read the whole thing as a path.

My filter matched 0 of 1545 rows in production, and the test fixture was the reason nobody noticed

Juan Camilo Auriti — Sat, 03 Oct 2026 11:00:00 +0000

A feature was shipping nothing. Not erroring, not slow — the list it was supposed to populate was empty, for everyone.

The cause was a filter matching on a string prefix:

def is_actionable(rec: str) -> bool:
    return rec.startswith("FIX:")

In production, 0 of 1545 rows started with FIX:. The prefix had been dropped upstream months earlier, in a change that had nothing to do with this code and looked entirely safe.

The test that passed

def test_is_actionable():
    assert is_actionable("FIX: add a canonical tag")
    assert not is_actionable("INFO: nothing to do here")

That test is green, and will stay green forever, and tells you nothing.

Because I wrote the fixture by reading the filter. The string "FIX: add a canonical tag" exists in my repository for exactly one reason: the function I was testing looks for FIX:. It is not a sample of anything. It's the function's own precondition, restated as data and then asserted on.

So the test verifies that startswith works. Python already had that covered.

The shape of the bug

The filter has two halves and only one of them is in the code:

Given a string with the prefix, do the right thing. In the function. Tested. Correct.
Production strings have the prefix. Nowhere. Untested. False.

Half two is an assumption about a different system — whatever produces those records. When that system changed, nothing in my repository was watching, because nothing in my repository contained a real example of its output.

A fixture written from the code under test can only ever check half one. That's the whole failure mode, and it's invisible from inside the test file, which reads as perfectly reasonable.

What I added

Not more unit tests. A test on the population.

def test_filter_matches_some_real_records(db):
    total = db.count("records")
    assert total > 0, "no records to check against"
    matched = db.count("records", where=is_actionable)
    assert matched > 0, (
        f"is_actionable() matched 0 of {total} real records — "
        f"the shape it expects no longer exists upstream"
    )

Three things about this that took me a couple of tries.

assert total > 0 first. Without it, an empty table makes the second assertion vacuously... well, it makes it fail, which sounds fine, but the message is then misleading — it says the filter is wrong when the fixture is empty. Guard the denominator and the failure tells you which of the two things broke.

matched > 0, not a percentage. I wanted matched / total > 0.1 and I was wrong to. The ratio is a business fact that legitimately drifts, and a threshold on it produces a test that fails on a good day. Zero is the only number that unambiguously means the contract is gone.

It has to run against real shapes. A sample of production data, an anonymised snapshot, a staging DB, or the smallest thing that works: a handful of real strings copied out of production into a fixture file, with a comment saying where they came from and when. Not strings you wrote — strings the upstream system wrote.

The rule I took out of it

A fixture derived from the code under test can prove the code is self-consistent. It cannot prove the code is right about the world.

Every filter, parser, regex, or mapping that consumes data from somewhere else has this second half, and the second half is where the outages live — because it breaks without anyone touching your file.

The cheap version, if you add nothing else: one assertion, anywhere in your suite, that the filter matches at least one real record. It catches the entire class, and unlike a unit test it fails when the world changes rather than when you change.

How I'd find the next one

Grep your codebase for string-shape assumptions about foreign data — startswith, endswith, a hardcoded key, a regex with a literal prefix, an enum comparison against a string from an API:

grep -rnE '\.startswith\(|\.endswith\(|re\.(match|search)\(r?"[^"]*\^' --include='*.py' .

For each hit, ask the question that isn't in the test file: what proves that shape still arrives? If the answer is a fixture you wrote, you have this bug and it's dormant, not absent.

Mine was dormant for months. The tests were green the whole time, and green tests are how it stayed dormant.

Git bundle verify said "complete history". git clone exited 0. The working tree was empty

Juan Camilo Auriti — Fri, 02 Oct 2026 11:00:00 +0000

I needed to move commits between two machines with no network route between them, so: git bundle. Write the bundle, copy it across, clone from it.

I checked my work the way you're supposed to:

$ git bundle verify transfer.bundle
9c824386e56b3c496c45823acc195283c024bccc refs/heads/main
The bundle records a complete history.

Complete history. Then:

$ git clone transfer.bundle restored
Cloning into 'restored'...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
$ echo $?
0
$ ls restored
$

Exit status 0. A .git directory. No branches. No files.

What the bundle was missing

A HEAD. That's it.

$ git bundle list-heads transfer.bundle
9c824386e... refs/heads/main

One ref. git clone needs to know which ref to check out, and it resolves that through the bundle's HEAD. There isn't one, so it falls back to a default that the bundle doesn't contain — you can see the wreckage afterwards:

$ git -C restored symbolic-ref HEAD
refs/heads/master
$ git -C restored branch
$

HEAD points at refs/heads/master, which does not exist, because the bundle carried main. The objects are all there. Nothing is corrupt. git log main inside that clone works fine. There is simply no branch and no checkout.

What I assumed, and why it was wrong

I had this filed in my head as "don't build bundles from refs/remotes" — I'd made the bundle from refs/remotes/origin/main the first time, and blamed that.

Wrong. I tested both:

bundle created from	`verify`	files	branch
`refs/remotes/origin/main`	complete history	0	none
`main` (i.e. `refs/heads/main`)	complete history	0	none
`--all HEAD`	complete history	1	`main`

The local ref behaves exactly as badly. The refs/remotes detail was a coincidence I'd turned into a rule. The actual requirement is the HEAD ref, and nothing in verify's output is sensitive to it.

The incantation

git bundle create transfer.bundle --all HEAD

--all takes every ref; HEAD adds the one that makes it clonable. That bundle lists four heads including HEAD, and the clone checks out a working tree with a branch on it.

If you want one branch rather than everything:

git bundle create transfer.bundle main HEAD

Why this is worse than a failure

Every signal available to a script says success.

git bundle verify exits 0 and prints a sentence containing the word complete. git clone exits 0. Under set -e, nothing stops. The only evidence is a warning: on stderr, and a transfer script that logs stdout — or pipes through tail, or runs under a CI step that only surfaces failures — will never show it to anyone.

The failure lands later, somewhere unrelated, as "the repo on the other machine is empty."

The check that costs nothing

verify answers "are the objects intact". It does not answer "is this clonable". So assert the thing you actually want, after cloning:

set -euo pipefail

git bundle create "$B" --all HEAD
git bundle verify "$B"

git bundle list-heads "$B" | grep -qw HEAD \
  || { echo "bundle has no HEAD ref, clone would produce an empty tree" >&2; exit 1; }

git clone -q "$B" "$DEST"
git -C "$DEST" rev-parse --verify HEAD >/dev/null \
  || { echo "cloned repo has no resolvable HEAD" >&2; exit 1; }

Two lines of assertion, and they're the two questions verify doesn't answer: is there a HEAD in the bundle, and did the clone end up on a commit.

The general shape, which is the part worth keeping: a verify step that checks integrity is not a verify step that checks usability. Anything you move between machines wants an assertion on the property you actually need at the destination — the objects being intact is necessary and nowhere near sufficient.

Tested on git 2.34.1. If your version prints something friendlier than a stderr warning, good — mine didn't, and the exit code is 0 either way.

How I close a monthly dataset, and the month I found out mine had been lying

Juan Camilo Auriti — Thu, 01 Oct 2026 11:00:00 +0000

I publish a monthly report from my own audit data. First of the month, one edition, findings only from the window that just closed.

The rules that make it publishable are almost entirely rules about what gets thrown out. I learned most of them the expensive way, and one of them by discovering that a number I had already published was computed from a table where the majority of rows were an artifact of a bug.

The rule that came first

No numerical findings before the data exists.

That sounds too obvious to write down. It isn't, because the pressure runs the other way: you have a publication slot on the first of the month, an outline, a headline shape you like, and a dataset that hasn't closed. It is very easy to write "early data suggests" around a number you don't have yet and backfill it.

So the rule is mechanical. The window closes on the last day of the month. Nothing gets written before that. If the data doesn't support a section, the section doesn't ship — not "ships with a hedge."

The hedge is the tell. "Early signals indicate", "we're seeing", "trending toward" — every one of those is a sentence written before the number existed, and I have yet to write one that turned out to be worth keeping.

The month the dataset was lying

I found a normalization bug: two spellings of the same URL living as separate rows, and a scheduled job that read one and wrote the other, so it re-audited forever. The mechanism has its own post earlier in this series. What matters here is the number that fell out of the cleanup.

86.9% of the rows in the audit table were produced by that loop. One domain alone had 1831 rows; after the fix and the merge it had 19.

Every aggregate I had computed from that table was weighted by which domains happened to be caught in the loop. Not slightly wrong — wrong in a way that has no relationship to the question I was asking, because the loop's victims were selected by URL spelling, which correlates with nothing.

I had already published from it.

What that added to the rules

Distinct entities, not rows. Every aggregate counts distinct domains, never raw rows. If one domain can contribute 1831 rows to a mean, the mean is that domain's opinion.

-- one observation per domain per window, most recent wins
WITH per_domain AS (
  SELECT DISTINCT ON (domain_id) domain_id, score, created_at
  FROM reports
  WHERE created_at >= :window_start AND created_at < :window_end
  ORDER BY domain_id, created_at DESC
)
SELECT count(*) AS domains, count(score) AS scored, round(avg(score), 1) AS mean_score
FROM per_domain;

DISTINCT ON with a matching ORDER BY is the whole guard. Drop the ORDER BY and Postgres gives you an arbitrary row per domain, which is a different and much subtler bug than the one I was fixing.

And note there are two counts in that select, which is not padding. count(*) counts domains; avg(score) silently skips NULLs. Run it on a window where three domains produced a score and one didn't, and you get domains = 4 next to a mean computed from three values. Publish the first number as the denominator of the second and you have overstated your sample in exactly the way this whole post is about — with a query I wrote for this post, which is how I found it. count(score) is the honest denominator for anything derived from score.

Publish the denominator. Every figure ships with the count behind it — and it has to be the count of values that fed that figure. It's the number a reader needs to weigh the claim, and — more usefully — it's the number that would have caught my bug. A mean over "1963 reports" and a mean over "19 domains" look nothing alike, and I would have noticed the first time the denominator was two orders of magnitude off from my mental model.

A minimum n, decided before looking. Segments below it get reported as "not enough data" rather than as a number with a caveat. Deciding the floor after seeing the segments is how you end up with a floor that happens to include the interesting result.

One derived story at a time, capped. A closed dataset can produce endless spin-offs, and each one is a chance to re-slice until something looks significant. A hard cap per edition — mine is three — makes that a budget instead of a temptation.

What gets thrown out, concretely

Runaway rows — anything from a job that didn't converge. Not de-weighted. Deleted, then the aggregate re-run.
Self-audits. My own domains, my staging environments, the test fixtures that point at real URLs. They cluster at high scores for obvious reasons and they were in my table.
Single-domain outliers driving a segment. If removing one domain moves a segment's headline, the segment isn't a finding, it's that domain.
Anything I can't recompute. If I can't re-derive a figure from the closed window with a query I can paste into the report's own notes, it doesn't go in. This one kills more sentences than all the others together, and it kills the ones I'm most attached to — the ones I "remember" from looking at a dashboard.

The uncomfortable part

The bug didn't come from carelessness in the analysis. It came from the analysis trusting the storage layer, which was written months earlier by someone with different concerns — me, not thinking about aggregates.

There's no rule that prevents that. The closest I have is: before the first aggregate of a new window, count the rows and count the distinct entities, and look at the ratio. If it's not roughly what you'd expect, stop and find out why before computing anything else.

Mine was 1963 to 19 in the worst case. I never looked, because the ratio isn't a finding — it's plumbing, and plumbing doesn't make it into an outline.

The report itself goes out today, on my own site. This post is the method, not the findings — the numbers live there.

78% of my reports had nothing to say, and I spent a month tuning the wrong thing

Juan Camilo Auriti — Wed, 30 Sep 2026 11:00:00 +0000

I looked at what my monitoring product had actually been sending people.

78% of reports showed a delta of exactly zero. Nothing had changed since the previous run. The report was correct, on time, and empty.

My first reading was that my change-detection thresholds were too coarse — that real movement was happening below the granularity I was measuring, and a finer scale would surface it. I spent a while on that. I wrote about the alert side of it earlier in this series, and about the backtest that talked me out of the tuning; this is the part I got wrong underneath it, which is different and worse.

The thresholds weren't the problem. The artifact was the problem. A report whose content is "no change" is not a report with a sensitivity issue. It's a report with nothing in it.

Why "no change" is the expected state

Once you say it out loud it's almost embarrassing.

Someone signs up, runs an audit, gets a list of problems, fixes some of them, and stops. That's the success path. Their site is now static in the dimensions I measure, because sites are static in those dimensions. robots.txt doesn't drift. Schema markup doesn't decay. A well-formed llms.txt stays well-formed until somebody edits it, and nobody edits it.

So the population my weekly report addresses is mostly people for whom the honest answer is "nothing happened, and that's fine." Which is not a message worth an email, and definitely not worth a dashboard visit.

The uncomfortable implication: a monitoring product for a slow-moving signal has no natural weekly cadence. I had assumed one because monitoring products have weekly reports. That's an industry convention, not a property of my data.

What I'd actually measure now

The metric I was missing isn't a threshold. It's a property of the output:

What fraction of generated artifacts contain at least one thing the recipient didn't already know?

Call it content rate. Mine was 22%. Every product decision downstream looks different once you know that number, and none of them are threshold changes:

Change the cadence to match the signal. Not weekly because it's Tuesday. Send when there's something, and say so — "we watched, nothing moved" is a fine thing to put in a monthly digest and a bad thing to put in a weekly email.

Add signals that actually move. The things I was measuring are properties of a site the owner controls, so they change only when the owner acts. Competitor position, whether a citation appeared or disappeared, a new crawler user-agent showing up in the logs — those move without the user doing anything, which is exactly what makes them worth telling someone.

Make stability an explicit product claim, or drop it. "Nothing changed" is genuinely valuable information if the product is framed around confirming that. It's dead weight if the product is framed around finding problems. I had the second framing and the first output.

The measurement, if you want to run it on yours

If you generate a recurring artifact — report, digest, alert summary, weekly email — this is the query. Mine is scores, yours is whatever the artifact is about:

WITH ranked AS (
  SELECT
    domain_id,
    score,
    LAG(score) OVER (PARTITION BY domain_id ORDER BY created_at) AS prev
  FROM reports
)
SELECT
  count(*)                                        AS reports,
  count(*) FILTER (WHERE prev IS NOT DISTINCT FROM score) AS unchanged,
  round(100.0 * count(*) FILTER (WHERE prev IS NOT DISTINCT FROM score) / count(*), 1)
                                                  AS pct_unchanged
FROM ranked
WHERE prev IS NOT NULL;

IS NOT DISTINCT FROM rather than = is the detail that matters: NULL = NULL is NULL, which is not true, so a plain = silently drops every pair where a score was missing — and missing scores cluster exactly where something odd is happening. IS NOT DISTINCT FROM treats two NULLs as equal and gives you the honest count.

Then read the number as a statement about your product rather than your thresholds. If most of your artifacts are empty, no amount of sensitivity tuning fills them.

The part I'd tell myself in advance

I spent weeks on threshold work because threshold work feels like the right kind of effort. It's measurable, it's in code, it produces diffs, and at the end of a day of it you can point at something.

Asking "should this report exist at all" produces no diff. It's also the question that was load-bearing, and I avoided it for a month by staying busy adjacent to it.

The tell, in hindsight: I was tuning the sensitivity of a detector without ever having measured how often the thing it detects occurs. That ordering is backwards, and it's a cheap check — one query, before the tuning, not after.

FastAPI's detail has two shapes, and the second one shows your users [object Object]

Juan Camilo Auriti — Tue, 29 Sep 2026 11:00:00 +0000

A user hit a validation error on a form and the page told them:

[object Object]

The frontend line responsible is one you have written, probably today:

errorEl.textContent = data.detail || "Something went wrong"

That line is correct for every error my API raises deliberately, and broken for an entire class of error I never wrote.

Two shapes

When you raise it yourself, detail is whatever you passed — normally a string:

raise HTTPException(status_code=403, detail="This domain isn't yours")

{ "detail": "This domain isn't yours" }

When Pydantic rejects the request body, FastAPI builds the 422 for you, and detail is an array of objects:

class AuditRequest(BaseModel):
    url: HttpUrl

    @field_validator("url")
    @classmethod
    def no_private_hosts(cls, v):
        if is_private(v.host):
            raise ValueError("private addresses are not allowed")
        return v

{
  "detail": [
    {
      "type": "value_error",
      "loc": ["body", "url"],
      "msg": "Value error, private addresses are not allowed",
      "input": "http://169.254.169.254/"
    }
  ]
}

Same key. Same status family. Two incompatible types.

Why the `||` doesn't save you

data.detail || fallback is a truthiness check, and a non-empty array is truthy. So the fallback never fires — the array wins, and textContent stringifies it with Array.prototype.toString, which joins the elements, each of which stringifies as [object Object].

One validation error prints [object Object]. Two print [object Object],[object Object], which at least looks broken enough that someone files a bug.

This is the specific reason it survives to production: the failure needs a request that is malformed, not merely rejected. Every hand-raised error works. Every happy path works. Your tests assert on status codes and on detail for the errors you wrote. Nobody writes a test asserting on how a validator's error message renders in the DOM.

The unroller

Handle both shapes once, at the boundary where the response becomes a message:

export function extractError(data, fallback = "Something went wrong") {
  const d = data?.detail
  if (typeof d === "string" && d.trim()) return d
  if (Array.isArray(d)) {
    const msgs = d
      .map(e => {
        const field = Array.isArray(e?.loc) ? e.loc.filter(p => p !== "body").join(".") : ""
        const msg = typeof e?.msg === "string" ? e.msg : ""
        if (!msg) return ""
        return field ? `${field}: ${msg}` : msg
      })
      .filter(Boolean)
    if (msgs.length) return msgs.join(" · ")
  }
  if (typeof d === "string") return fallback   // empty/whitespace string
  return fallback
}

The parts that are there because I got them wrong first:

loc.filter(p => p !== "body"). The raw loc is ["body", "url"]. Showing a user body.url: ... leaks your request schema into the UI for no benefit. Drop the container, keep the field.

Guard every element. e.msg is a string in every FastAPI version I've used, but this function's entire job is to survive a shape it didn't expect. A .map that assumes will throw inside your error handler, which is the worst possible place to throw.

.filter(Boolean) then check length. If every element yields an empty message you must fall through to the fallback, not return "" — an empty string assigned to textContent produces a silent, blank error state, which is worse than the wrong message because nobody reports it.

Trim the string case. detail: " " is truthy and renders as nothing. Same silent-blank failure.

Or flatten it server-side

If you own both ends, the other fix is to stop emitting the union at all:

from fastapi import FastAPI, Request
from fastapi.exceptions import RequestValidationError
from fastapi.responses import JSONResponse

@app.exception_handler(RequestValidationError)
async def validation_handler(request: Request, exc: RequestValidationError):
    parts = []
    for e in exc.errors():
        field = ".".join(str(p) for p in e["loc"] if p != "body")
        parts.append(f"{field}: {e['msg']}" if field else e["msg"])
    return JSONResponse(status_code=422, content={"detail": " · ".join(parts)})

Now detail is always a string and the original one-liner is correct.

I did both. The handler is the real fix — one type, one contract. extractError stays because a frontend that trusts a single shape is one upstream change away from [object Object] again, and because third-party middleware can produce a 422 that never reaches my handler.

The transferable bit

detail is a documented union type that reads like a scalar. FastAPI isn't doing anything wrong; it's in the spec. The trap is that JavaScript's truthiness makes a union look handled when only one arm of it is.

So: anywhere you write x || fallback against a value that crosses a network boundary, the question isn't "can it be missing" — || has that covered. It's "can it be present and the wrong type". That's the case || silently passes through to the DOM.

Fastest way to find yours: point your form's own validator at a malformed request and look at what your UI actually says. Mine said [object Object] for weeks, in a field a user reads only when they're already stuck.

DEV Community: Juan Camilo Auriti

YouTube is the #1 cited domain in Google AI Overviews. Reddit is #2. Your blog is nowhere.

Why YouTube dominates

Reddit as the second pillar

What this means if you produce written content

The uncomfortable part

55% of AI Overview citations come from the first 30% of your page. Here's the data.

The CXL study: 100 AI Overview citations

The Kevin Indig dataset: 18,012 ChatGPT citations

Why this happens

What the Ahrefs data adds

Practical changes

What this does not mean

Google's mythbusting guide says stop obsessing over Schema. The data agrees.

llms.txt: the file 97% of sites publish for nothing

Schema.org: necessary, but not the lever GEO agencies sell

Chunking: the tactic with no public evidence

What the data says actually works

What this means for your audit

Google said llms.txt does nothing. I checked what 137,210 domains actually got.

What Google said

What Google did next

Study 1: Ahrefs, 137,210 domains

Study 2: SE Ranking, 300,000 domains

Study 3: OtterlyAI, 90-day server log experiment

Study 4: Limy, 515 million bot events

What actually works (according to the same studies)

What I did with my own tool

The bottom line

I deployed the fix, restarted, saw nothing, and reverted a change that worked

The suppression

Why I believed the wrong thing

What to check instead

The general shape

Dependabot was watching 2 of my 6 updatable surfaces, and the config looked complete

What was missing, and why each was easy to miss

The audit command

The other half: a skipped PR doesn't come back

Why it looked complete

input type="url" rejects the URL before your normalizer ever runs

Why

Three fixes, in the order I'd try them

Don't fix it by deleting the validation

Check every surface, not the one in the bug report

My filter matched 0 of 1545 rows in production, and the test fixture was the reason nobody noticed

The test that passed

The shape of the bug

What I added

The rule I took out of it

How I'd find the next one

Git bundle verify said "complete history". git clone exited 0. The working tree was empty

What the bundle was missing

What I assumed, and why it was wrong

The incantation

Why this is worse than a failure

The check that costs nothing

How I close a monthly dataset, and the month I found out mine had been lying

The rule that came first

The month the dataset was lying

What that added to the rules

What gets thrown out, concretely

The uncomfortable part

78% of my reports had nothing to say, and I spent a month tuning the wrong thing

Why "no change" is the expected state

What I'd actually measure now

The measurement, if you want to run it on yours

The part I'd tell myself in advance

FastAPI's detail has two shapes, and the second one shows your users [object Object]

Two shapes

Why the || doesn't save you

The unroller

Or flatten it server-side

The transferable bit

Why the `||` doesn't save you