Written by Trevor Indrek Lasn @ trevorlasn.com --- title: You have been invited to the 0xInsider.com Discord server! description: Join the 0xInsider.com Discord community — talk markets, odds, and predictions with fellow prediction market traders in real time. topics: ['prediction markets', 'tech'] --- # You have been invited to the 0xInsider.com Discord server! We just opened up a Discord server for prediction market enthusiasts, and we'd love for you to be part of it. It's a space to discuss market moves, debate odds, share forecasts, and swap strategies with other traders. Whether you want to dig into a specific market or just see what everyone's watching, there's a spot for you. ### What You'll Find Here - **Real-time market talk** — react to moves on Polymarket and Kalshi as they happen - **Odds and forecast debates** — argue your read, pressure-test someone else's - **Strategy swaps** — share what's working and learn what isn't - **Whale trade discussion** — break down the large trades [0xInsider](https://www.0xinsider.com) surfaces Whether you're deep into a specific market or just want to see what everyone's watching, there's a spot for you. ### Join Us Ready to talk markets, odds, and predictions with fellow traders? [Join the 0xInsider.com Discord](https://discord.gg/JxJsnbeYhn) See you inside! --- --- title: Ph.D in failure, Masters in getting back up description: Every time I bet on myself instead of taking a paycheck, and what each one taught me. topics: ['reflections'] --- # Ph.D in failure, Masters in getting back up I've failed a lot, more than most people would care to admit, and I'm proud of it. Everything below is something I bet on myself to build, and most of it didn't work. That's the point. Each failure taught me something a steady paycheck never could. My day jobs as an engineer and manager aren't on this list, only what I built for myself. **2010-2013 · pro gaming.** Semi-pro League of Legends. I started on top lane, then switched to jungle and climbed to around 2750 elo in Season 2, good enough to solo queue against pros and scrim with pros and semi-pros. I wanted to make it work, but the pieces never quite fit. Pro gaming was an opaque path back then with no clear way in, and I couldn't make a convincing case for it. My parents didn't see it as a real career, and I wasn't able to explain it well enough to change their minds. By Season 3 I put more into school, and that was that. It didn't pan out as a career, but that's around when I started learning to code. **Lesson:** talent without a path to get paid is just a hobby. I was early to a real industry, but being early without the conviction to back it is the same as being wrong. **2015-2022 · writing.** Writing tech articles, tutorials, and listicles, paid through the Medium Partner Program. That was the gig, and for a while it actually paid the bills. Then Medium lost ground in tech and the payouts dried up. The platform got flooded with low-effort, mass-produced filler, and the good writing drowned in the noise. **Lesson:** if you build your income on a platform you don't own, you're renting it. When Medium's economics changed, mine did too, and I had no vote. **2018 · startup 1.** A recipe site (lol). I wanted to learn Meteor.js and scratch my own itch: I wanted to cook more but never knew what to make, so I built a site to browse recipes. I shut it down not long after. The space was saturated with established brands that already owned the search rankings, and I had no edge to take them on. **Lesson:** know how it makes money before you build it. A content site needs enormous traffic just to clear minimum wage, and I'd confused shipping something with building a business. **2018 · startup 2.** Linktree, but for crypto addresses. I branded it at the time as one payment link for all your crypto: you put every address under a single link and shared that. I had no idea how to monetize it and wasn't business-savvy enough to figure it out. **Lesson:** a free utility anyone can clone is a feature, not a company. "Useful" and "fundable" are different questions, and I never asked the second. **2019 · startup 3.** A mashup of LinkedIn and Crunchbase. One place to look up a person and the company behind them at once: who works where, who raised what, who to reach out to. Handy for sales and recruiting on paper. In reality the data was a pain to keep fresh, I had no distribution, and I drifted off before working out who would actually pay for it. **Lesson:** reselling data you don't own is a treadmill, not a moat. The build was never the hard part. Distribution and a reason to pay were, and I'd skipped both. **2022 · startup 4.** Reddit, but for podcasts. You could submit podcast links, upvote and downvote them, and leave comments, so the best episodes would rise to the top instead of getting buried in someone's feed. I liked the idea of a community-curated front page for audio. It never reached the critical mass a voting site needs: with too few users there was nothing to vote on, and with nothing to vote on nobody stuck around. A classic cold-start problem, and I had no plan to solve it. **Lesson:** a community product is worthless until it's crowded, so the only question that matters is how you get the first thousand people. I had no answer. **2023 · startup 5.** Burned out on tech, so I pivoted to fashion design and launched two brands: a clothing label and a 3D-printed jewelry line. It actually went well for a while, but I shut both down. Not enough traction to justify keeping at it, and not enough passion to push through that. **Lesson:** work on something you care about deeply. Passion is the fuel for the unglamorous middle, and without it even a business that's working won't hold you. **2023 · startup 6.** A text-based dating site. I was in a relationship at the time, but I still thought there was a market for something more conversation-first than the swipe apps. I built it and then never launched it, because I didn't want my name attached to the dating scene. **Lesson:** if you won't put your name on it, you've already decided. I just figured that out after building it instead of before. **2024 · startup 7.** A hiring platform for developers. You could filter jobs by the tech stack you actually work in to find roles that fit, and build a profile so companies reached out to you instead of you applying to them. Too much competition in the space, and not enough passion on my end to outlast it. **Lesson:** entering a crowded market without an unfair edge is volunteering to lose slowly. "Better" isn't an edge, "different in a way that matters" is. **2025 · startup 8.** A dashboard for engineering managers to run their org. It tracked the metrics that actually tell you how a team is doing: cycle time, how long code takes to ship, PR review turnaround, deployment frequency, change failure rate, and lead time for changes. I gave up before launch. Somewhere along the way I realized I wasn't passionate about the problem, and forcing it felt worse than walking away. **Lesson:** only build problems you'd happily live inside for a decade, because you'll have to. I quit before launch, and quitting early beats quitting late. **2025 · startup 9.** You'd tell an AI what you wanted to learn, and it would point you to vetted resources and courses instead of the pile of low-effort tutorials out there. I built my own vector database stuffed with the good stuff to power the recommendations. I closed it because AI search got too good too fast: Perplexity, Claude, and Google now do the same thing well enough that there was no room to compete. **Lesson:** don't build in the path of where the giants are already heading. When your core feature is a roadmap item for Google and OpenAI, you're a placeholder, not a competitor. **2026 · startup 10.** [0xinsider](https://0xinsider.com), the intelligence layer for prediction markets. A coworker got me into it. In a random conversation she mentioned her husband builds Polymarket bots, and I wanted to see what all the fuss was about. I went down the rabbit hole and never came back. I'm still building it, I love it, and I plan to be at this one for many years. After everything above, this is the one I'm all in on. **Lesson:** everything before this is why it's different. A market I'm obsessed with, a clear way to get paid, an edge in the data, and the conviction to stay. The failures weren't detours, they were tuition. --- --- title: AEO and GEO for AI Overviews, ChatGPT, Claude, Gemini, and Perplexity description: What Answer Engine Optimization and Generative Engine Optimization mean, and how to get your site cited by AI Overviews, ChatGPT, Claude, Perplexity, and Gemini. topics: ['webdev', 'tech'] --- # AEO and GEO for AI Overviews, ChatGPT, Claude, Gemini, and Perplexity Search results don't look the way they did two years ago. Google now opens with AI Overviews, ChatGPT and Claude pull live web results into their answers, Perplexity built an entire product around it, and Gemini sits one tap away inside every Google surface. The page is no longer the destination. The page is a source the model is reading on your behalf. Two acronyms have shown up to describe the work of being visible inside those answers. **AEO** stands for Answer Engine Optimization, which is the work of being the source an "answer engine" uses when it returns a direct answer instead of a list of links. **GEO** stands for Generative Engine Optimization, which is the same idea framed around generative AI specifically: appearing inside answers a model writes from scratch using your page as a reference. Google's own [AI optimization guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) treats both as variations of regular SEO. From their perspective, "optimizing for generative AI search is optimizing for the search experience, and thus still SEO." The ranking and quality systems that decide what shows up in a list of blue links are the same systems that decide what shows up inside an AI Overview. Improving for one improves the other. One reason this matters: each AI surface pulls from a different web index, but most of those indexes are downstream of the same crawl, rendering, and quality work. ``` Your page │ ▼ Search engine indexes (where the crawl lands) ┌────────────────────────────────────────────────────────┐ │ Google index ──▶ Google Search, AI Overviews, Gemini │ │ Bing index ──▶ Bing, Microsoft Copilot │ │ OpenAI index ──▶ ChatGPT Search │ │ Anthropic + Brave ▶ Claude web search │ │ Perplexity + Bing ▶ Perplexity answers │ └────────────────────────────────────────────────────────┘ │ ▼ The AI surface reads from the index, cites your page ``` The practical question is what you do to your site. The rest of this post walks through it, with sources for every recommendation. ### Eligibility comes before everything else Before any of the content work matters, the page has to be allowed to appear in AI features at all. Google's guide is explicit: a page is only eligible for AI features if it's eligible to appear as a regular search snippet ([source](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)). That means the URL needs to be indexed, the page needs to be crawlable in `robots.txt`, snippets need to be allowed (no `nosnippet`, no `max-snippet:0`), and the content has to load without requiring the crawler to execute heavy JavaScript first. Open Google Search Console and run a URL inspection on a page you care about. The "Test live URL" view shows you what Google sees, including the rendered HTML after JavaScript has executed. If the article body is missing from that rendered HTML, fix it before doing anything else. Google's [JavaScript SEO basics](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) covers the patterns that work and the ones that break crawling. Server rendering and static generation are the safest bets. A 30-second sanity check from your terminal, one per major AI crawler: ```bash # Google Search (feeds AI Overviews and Gemini grounding) curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" -I https://0xinsider.com/article # Bing (feeds Microsoft Copilot) curl -A "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" -I https://0xinsider.com/article # OpenAI search indexer (ChatGPT Search) curl -A "OAI-SearchBot/1.3; +https://openai.com/searchbot" -I https://0xinsider.com/article # Anthropic search indexer (Claude web search) curl -A "Claude-SearchBot/1.0 (+https://www.anthropic.com)" -I https://0xinsider.com/article # Perplexity indexer curl -A "PerplexityBot/1.0 (+https://perplexity.ai/perplexitybot)" -I https://0xinsider.com/article ``` A `200 OK` from a spoofed user agent isn't proof that the real crawler can reach the page. Bot operators block UA spoofing, so the only authoritative check is to verify the request against published IP ranges or reverse-DNS records. Google documents its [crawler verification process](https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot), and OpenAI, Anthropic, and Perplexity all publish IP ranges in their bot docs. Use the `curl` test to catch obvious blocks (a `403`, `503`, or login-page redirect that suggests Cloudflare's bot-fight rule or a misconfigured WAF), then confirm against the official IP list for the bots that matter to you. The full list of bots worth thinking about, with what they do and the canonical reference: ``` Bot user agent Purpose Reference ────────────────────────────────────────────────────────────────────────── Googlebot Google Search index developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers Google-Extended Gemini Apps + Vertex AI Grounding + developers.google.com/crawling/docs/crawlers-fetchers/google-special-case-crawlers AI training (separate from Search) Bingbot Bing index (feeds Copilot) bing.com/webmasters/help/which-crawlers-does-bing-use-8c184ec0 GPTBot/1.3 OpenAI training developers.openai.com/api/docs/bots OAI-SearchBot/1.3 ChatGPT Search live index developers.openai.com/api/docs/bots ChatGPT-User ChatGPT user-initiated fetch developers.openai.com/api/docs/bots ClaudeBot Anthropic training support.claude.com/en/articles/8896518 Claude-SearchBot Anthropic search index (Claude search) support.claude.com/en/articles/8896518 Claude-User Claude user-initiated fetch support.claude.com/en/articles/8896518 PerplexityBot Perplexity search index docs.perplexity.ai/docs/resources/perplexity-crawlers Perplexity-User Perplexity user-initiated fetch docs.perplexity.ai/docs/resources/perplexity-crawlers Applebot-Extended Apple Intelligence training support.apple.com/en-us/119829 Meta-ExternalAgent Meta AI training developers.facebook.com/docs/sharing/webmasters/web-crawlers CCBot Common Crawl (feeds many models) commoncrawl.org/ccbot ``` A `robots.txt` you can copy that allows AI search visibility (the surfaces that cite your page) while opting out of training (the bots that scrape for model training data): ``` # Allow indexing for search and AI search surfaces User-agent: Googlebot Allow: / User-agent: Bingbot Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / User-agent: Claude-SearchBot Allow: / User-agent: Claude-User Allow: / # Block AI training crawlers (does not affect Google Search inclusion) User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: Applebot-Extended Disallow: / User-agent: Meta-ExternalAgent Disallow: / User-agent: CCBot Disallow: / # Fallback User-agent: * Allow: / Sitemap: https://0xinsider.com/sitemap.xml ``` The distinction matters. `GPTBot` and `ClaudeBot` are training crawlers, and blocking them does not affect search inclusion. `Google-Extended` is broader: it controls AI training **and** grounding inside Gemini Apps and Vertex AI Grounding, but does not affect Google Search ranking or AI Overview eligibility ([Google source](https://developers.google.com/crawling/docs/crawlers-fetchers/google-special-case-crawlers)). The bots that determine whether your page can show up inside an AI answer are the search indexers: `Googlebot`, `Bingbot`, `OAI-SearchBot`, `Claude-SearchBot`, and `PerplexityBot` ([OpenAI source](https://developers.openai.com/api/docs/bots), [Anthropic source](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler), [Perplexity source](https://docs.perplexity.ai/docs/resources/perplexity-crawlers)). Many sites accidentally block one of those and tank their visibility. Meta robots tags are the other lever, page-level rather than site-level: ```html ``` To opt out of `Google-Extended` (Gemini Apps and Vertex AI Grounding), use the `robots.txt` product token shown earlier. Google does not document `Google-Extended` as a robots meta tag, only as a `robots.txt` token ([source](https://developers.google.com/crawling/docs/crawlers-fetchers/google-special-case-crawlers)). The snippet directives above are documented in Google's [meta tags reference](https://developers.google.com/search/docs/crawling-indexing/special-tags). ``` Page exists │ ▼ robots.txt allows crawl? ── no ──▶ invisible ▼ page renders without JS errors? ── no ──▶ invisible ▼ indexed in Search Console? ── no ──▶ invisible ▼ snippet allowed (no nosnippet)? ── no ──▶ regular search only ▼ quality + originality signals? ── weak ─▶ ranked, rarely cited │ ▼ Eligible to appear in AI Overviews and related surfaces ``` Every layer is a gate. The fancier optimization work only matters once all the gates are open. ### What gets cited is what a model can't write from training data alone Generative search rewards specificity. Models can summarize generic information without quoting anyone, so the pages that get cited are the ones that say something the model can't synthesize on its own. Google's guide tells creators to focus on "unique, valuable, people-first content" rather than commodity content that re-states what every other page on the topic already says ([source](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)). The deeper version of this advice lives in Google's [helpful content guidance](https://developers.google.com/search/docs/fundamentals/creating-helpful-content), which goes into how to demonstrate firsthand experience, real expertise, and original perspective. Here are two real versions of the same paragraph for an article about migrating to Next.js 16. Same topic, same word count, wildly different odds of being cited: ``` Commodity version: "Next.js 16 introduces async params, making route parameters asynchronous. This is a breaking change you should plan for when upgrading from Next.js 15. Make sure to await your params in dynamic routes." Distinctive version: "We migrated a 240-route Next.js 15 app to 16 last week. The async params change broke 47 pages in CI on the first run. The mechanical fix: wrap every `params.slug` access in `await params`. The catch we hit: dynamic API routes that destructure params in the function signature need the signature itself marked async, not just the body. Took 3 hours, almost all of it search-replace." ``` A model can produce the commodity version from training data alone, so it won't cite the source. There's nothing in there it couldn't write itself. The distinctive version has a number (47 broken pages), a specific catch (the function signature subtlety), and a time estimate (3 hours), none of which the model can generate without quoting the source. Even one of those details is often enough to flip a page from "training data summary" to "cited reference". ``` What the model sees about your topic │ ├──▶ Commodity content │ "Same overview 50 other pages have" │ │ │ ▼ │ Model synthesizes from training data │ │ │ ▼ │ Not cited │ └──▶ Distinctive content "Specific data, screenshot, opinion, result you tested in production" │ ▼ Model can't synthesize, must quote │ ▼ Cited in the answer ``` ### Clean technical structure helps the crawler and the model Semantic HTML matters. Use real heading levels in a sensible hierarchy, put the answer to the question the page is about near the top, and avoid burying content under preamble. A real before/after on the same blog post: ```html
How to migrate to Next.js 16
A practical guide
We migrated 240 routes last week...

How to migrate to Next.js 16

A practical guide to async params, Turbopack defaults, and the gotchas we hit.

Async params, in practice

We migrated 240 routes last week...

``` The second version gives the crawler clear structure (`article`, `h1`, `section`, `h2`) and the model clean boundaries for what's heading, lede, and body. Google's documentation on [page experience](https://developers.google.com/search/docs/appearance/page-experience) explains how Core Web Vitals feed into ranking, which feeds directly into AI feature eligibility. The thresholds Google publishes ([source](https://web.dev/articles/vitals)): ``` Metric Good Poor ───────────────────────────────────────────────────── LCP Largest Contentful Paint ≤ 2.5s > 4.0s INP Interaction to Next Paint ≤ 200ms > 500ms CLS Cumulative Layout Shift ≤ 0.1 > 0.25 ``` The numbers ranking algorithms look at are the 28-day field data from real Chrome users (CrUX), not a Lighthouse run on your laptop. Read them from `web-vitals` in JavaScript to align local testing with what Google's systems see: ```js onLCP(metric => console.log('LCP', metric.value, metric.rating)); onINP(metric => console.log('INP', metric.value, metric.rating)); onCLS(metric => console.log('CLS', metric.value, metric.rating)); ``` The AI optimization guide also pushes back on several "optimization hacks" circulating online. Adding an `llms.txt` file is not a ranking signal and isn't used by Google's AI features ([source](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)). Chunking content into tiny sections or rewriting every heading as a question is unnecessary, because models read context across the whole page. The guide also says structured data is useful where it powers a documented rich result, but it isn't required for AI feature visibility. Spend the time on real content quality and rendering instead. ``` What the crawler fetches ───────────────────────────────────────────────────────── Server-rendered HTML Client-only SPA shell ───────────────────── ─────────────────────

Title

Real content...

``` Test it inside Google's [Rich Results Test](https://search.google.com/test/rich-results) before deploying. The tool will tell you exactly which required fields are missing or malformed. If you run a local business or sell products, two unrelated surfaces matter more than schema. A verified [Google Business Profile](https://support.google.com/business/answer/3038063) feeds local AI answers with your hours, location, services, and reviews. A [Merchant Center](https://support.google.com/merchants/answer/188494) feed is what AI Overviews pull product information from. The AI optimization guide names both explicitly as the primary input for business and commerce results ([source](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)). ``` Type of result Source feed Where it shows ──────────────────────────────────────────────────────────────────── Local business ◀── Google Business Profile ──▶ Maps, local panel, (hours, location, reviews) local AI answers Products ◀── Merchant Center feed ────▶ Shopping cards, (price, stock, variants) product AI answers Recipes, FAQs, ◀── Schema.org JSON-LD ──────▶ Rich results, events, articles (on-page structured data) AI understanding ``` ### Agentic experiences are the next surface The newer wrinkle is autonomous agents browsing on the user's behalf (Claude with computer use, ChatGPT Operator, Perplexity's assistant). Google's AI optimization guide recommends sites consider how agents interpret their DOM, controls, and content ([source](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)). Sites with confusing markup, hidden controls, or essential information rendered only as images are hard for agents to operate. The accessibility work you'd already do for screen readers covers most of the same ground. A real before/after of an interactive control on a booking page: ```html
``` The second version tells an agent three things: it's a submit button, the action is "Confirm booking", and the icon is decorative. The first version tells it nothing. An agent that can't identify the booking confirmation gives up and picks a site it can operate. Form fields work the same way. An agent reads `name`, `id`, `aria-label`, and the surrounding `