Author: Will Tygart

  • Second Restoration Location: Why $5M is the Threshold

    Second Restoration Location: Why $5M is the Threshold

    Most restoration owners get the second-location itch around $3M. The honest answer is they shouldn’t scratch it until $5M — and even then, only if a specific list of things is already true inside the first shop.

    Opening a branch is one of those decisions that looks like growth on the surface and turns into the slow bleed underneath. The mistake is almost never the second location itself. The mistake is the first location wasn’t ready to be left alone yet, and the owner went from running one healthy business to running two broken ones.

    Here’s the honest framework. Not the cheerleader version.

    Why $5M Is the Real Threshold (Not $3M)

    Industry valuation data makes this concrete: restoration shops under $2M trade at roughly 2.8x–3.0x SDE. Once you cross $5M with a diversified service mix, multiples jump to 4x–7x EBITDA. That gap is not just about revenue — it reflects what buyers see in the operation. A $5M shop has a real second layer of leadership. A $3M shop almost always doesn’t.

    When you open a second location from a $3M base, you are usually taking the only person who knows how to run the business — you — and splitting yourself in half. The first location’s gross margin starts compressing within ninety days. The new location burns cash for twelve to eighteen months before it stabilizes. Now you have two locations that both need you and neither one is the business it used to be.

    At $5M, you typically have an operations manager, a production manager, a dedicated estimator or project manager bench, and recurring TPA volume that doesn’t depend on the owner answering the phone. That is the difference. The threshold isn’t a dollar figure — it’s whether the first location can run a full week without you in the building.

    The Five Things That Have to Be True Before You Open

    Numbered checklist of five readiness conditions before opening location two
    Five things have to be true before you open.

    1. The first location can survive 30 days without you. Not “the work gets done.” That you can be unreachable for a month and the financials, the TPA scorecards, and the production schedule all stay inside normal range. If you can’t do that, you don’t have a second-location problem. You have a delegation problem at the first one, and adding geography won’t fix it.

    2. You have an operations manager who is not you and is not a relative. Family members can run a second location, but only if they were already running a P&L inside the first one. The second-location playbook is the operations manager playbook. If you don’t have someone who can hold gross margin, manage WIP, and run a weekly production meeting without you in the room, the branch will not work.

    3. The new market has documented demand, not a feeling. Pull the data before you sign a lease. Carrier referrals you’re already turning down in the target market. TPA territory gaps your existing programs have flagged. Search volume for “water damage restoration [city]” and the CPC on it. If the only reason you’re picking the market is that your cousin lives there or you saw a competitor’s truck, you don’t have a market — you have a hunch.

    4. The first location is throwing off enough cash to fund 18 months of branch burn. A new restoration location typically loses money for twelve to eighteen months. Plan for the long end. SBA expansion loans usually want a 1.25 DSCR before they’ll touch it, which means your existing operation has to be healthy enough to service the new debt while the branch is still in the red. If the math doesn’t work without the new location immediately producing, the math doesn’t work.

    5. Your tech stack scales without bolt-ons. If your job management software, Xactimate workflow, and TPA portal logins are all stitched together by tribal knowledge inside the first office, the second location will not run the same playbook. It will run a worse one. The system has to be portable before the branch opens, not after.

    What Most Owners Get Wrong

    Restoration technicians training in a shop bay with equipment demo and whiteboard
    Most owners get people depth wrong — not the lease math.

    The most common second-location failure pattern goes like this. Owner hits $3.5M. Owner is tired, ambitious, and has an opportunity — a competitor closing down, a key employee asking for an ownership path, a city forty-five minutes away that “doesn’t have anyone good.” Owner signs a lease, hires a production lead, and tells himself the branch will be self-sufficient by month six.

    Month six arrives. The branch is at 40% of projected revenue. The original location’s gross margin has slipped four points because the best production manager got moved to the new branch and the bench underneath wasn’t ready. The owner is driving between two offices three days a week. Cash is tight. The owner doubles down — hires another person, runs a Google Ads campaign in the new market, increases the burn — and by month eighteen the branch is either limping or being quietly wound down.

    This isn’t a hypothetical. It is the most common growth-stage failure in the industry, and it happens because the second location was opened as a revenue bet when it should have been opened as an operational bet.

    The Counter-Pattern: What Works

    Four-step flow: open skill, paste job facts, review draft, send or file
    Counter-pattern: repeatable runs beat hopeful maps.

    The owners who successfully open second locations almost always share three traits. First, they spent eighteen to twenty-four months building the leadership bench inside the first location before they ever talked about a branch. Second, they entered the new market with a known revenue floor — either a TPA program that committed volume, a large commercial client base in the geography, or a key person from the new market with their own book. Third, they treated the first six months of the branch as an investment, not a revenue line. They didn’t expect the branch to carry itself. They expected to lose money buying market presence and learning the territory.

    The phrase that separates the two camps is simple. Failed openings start with “we need to grow.” Successful openings start with “we have the team and the demand to grow.”

    The Bottom Line

    If you’re under $5M and you don’t have a real operations bench, do not open a second location. Spend the next twelve months building the bench, hardening the tech stack, and proving the first location can run without you. The valuation gap between a clean $5M single location and a $7M two-location operation where both are slightly broken is enormous — and it almost always favors the clean single.

    The second location is a multiplier. It multiplies whatever is true about the first one. If the first one is humming, you’ll build something worth selling for 5x EBITDA. If the first one is fragile, you’ll build two fragile ones and discover that the buyers paying premium multiples will pass on both.

    Build the bench. Document the playbook. Hit $5M with the owner out of the truck. Then open the second.

    Related on Tygart Media: company revenue · cash flow & profit · owner freedom kit.

  • ChatGPT Search Citations: The 2026 Optimization Guide

    ChatGPT Search Citations: The 2026 Optimization Guide

    ChatGPT Search cites 15% of the pages it retrieves. The other 85% get pulled into the model’s context window, evaluated, and silently discarded — no visibility, no referral, no trace. If you are doing GEO work and your pages keep getting retrieved but never quoted, you are losing at the second filter, not the first.

    This is the 2026 implementation guide for surviving both filters: getting retrieved by ChatGPT Search, then getting cited once you are there.

    How ChatGPT Search Actually Builds an Answer

    Topic platform fit visual for first-party AI citation measurement
    How ChatGPT Search builds an answer.

    ChatGPT Search runs a three-stage pipeline. Each stage kills most candidates.

    1. Retrieval — ChatGPT Search is powered by Bing’s index for real-time web retrieval. Seer Interactive’s analysis found 87% of SearchGPT citations match Bing’s top results, with the bulk in positions one through ten and a long tail in positions eleven through twenty. AirOps research separately put ChatGPT-to-Bing overlap at 73%. If you are not in Bing’s top 20 for a query, you almost certainly are not in ChatGPT’s candidate set.
    2. Crawlability check — OpenAI’s OAI-SearchBot is the user agent that builds the index used for ChatGPT’s search features. It is separate from GPTBot (training) and ChatGPT-User (browsing). Block OAI-SearchBot in robots.txt and you remove yourself from ChatGPT Search entirely, even if Bing has you ranked.
    3. Citation selection — Of the pages retrieved, AirOps found ChatGPT cites only 15%. The model picks what to quote based on structure, freshness, authority signals, and whether the page directly answers the query.

    Step 1: Verify You Are Indexed by Bing

    Most sites optimized for Google have never logged into Bing Webmaster Tools. Fix that first. Three checks before anything else:

    • site:yourdomain.com in Bing — confirms basic indexing.
    • Bing Webmaster Tools → URL Inspection — confirms the specific pages you want cited are indexed and have no crawl errors.
    • Bing rankings for your target queries — if you are not in the top 20 in Bing, ChatGPT will not see you.

    If pages are missing, submit a sitemap via Bing Webmaster Tools and request URL inspection on any priority page. Bing typically reflects changes within 24–72 hours, faster than Google.

    Step 2: Allow OAI-SearchBot in robots.txt

    Four ranked rows of AI crawler fleets reading publisher content
    Allow OAI-SearchBot in robots.txt.

    The single most-skipped step in GEO work. Add this block to your robots.txt:

    # Allow ChatGPT Search to retrieve and cite this site
    User-agent: OAI-SearchBot
    Allow: /
    
    # Optional: allow on-demand browsing for ChatGPT users
    User-agent: ChatGPT-User
    Allow: /
    
    # Optional: block training crawler if you want retrieval without training
    User-agent: GPTBot
    Disallow: /

    OpenAI publishes these three user agents and treats each independently. You can allow OAI-SearchBot for ChatGPT Search visibility and still disallow GPTBot from using your content for model training. The settings do not conflict. OpenAI’s systems typically recognize robots.txt changes within 24 hours.

    Step 3: Structure Pages for the Citation Filter

    Comparison of Claude how-to fit versus local service page fit for assistants
    Structure pages for the citation filter.

    Retrieval is necessary but not sufficient. Once your page is in the candidate set, the model decides whether to quote it. Pages that get quoted share a structural pattern.

    Direct answers in the first 100 words

    ChatGPT cites sources that answer the question fully. Partial answers lose to complete ones. Lead each page with a clean direct-answer paragraph: question implied or stated, answer in the next sentence, supporting detail after. This is the same pattern that wins featured snippets, which is not a coincidence — answer engines and snippet engines reward the same structure.

    JSON-LD schema

    An AirOps study of 548,534 pages found pages with JSON-LD markup posted a 38.5% citation rate versus 32.0% without it. Article, FAQPage, and HowTo schema are the highest-leverage types. Add them.

    Word count: 500–2,000

    Pages between 500 and 2,000 words performed best in the same AirOps study. Pages longer than 5,000 words were cited less often than pages under 500. The mechanism is mechanical: long pages overflow the retrieval context window, and the model defaults to shorter, denser sources it can quote in full.

    Freshness

    Content updated within 30 days received 3.2x more citations than older material. The fix is not faked freshness — it is genuine updates: a new stat, a new case, a corrected claim. Update the date when you update the content, not before.

    Step 4: Build the Authority Layer

    Structure gets you cited once. Authority gets you cited repeatedly. AirOps found sites with over 32,000 referring domains are 3.5x more likely to be cited by ChatGPT than sites with fewer than 200. You do not need 32,000 — you need to be in the upper band of your topical neighborhood.

    ChatGPT’s citation pattern leans heavily on Wikipedia (roughly 48% of top citations in multiple studies) and large news/media properties. The practitioner read on that: ChatGPT favors sources with multi-source third-party validation. Build the kind of citations on the open web that Wikipedia editors accept — peer-reviewed studies, primary sources, named author attribution, transparent methodology.

    Step 5: Track Your Citation Footprint

    You cannot manage what you do not measure. The minimum tracking stack for 2026:

    • Server log monitoring for OAI-SearchBot user agent — confirms OpenAI is actually crawling. If you allowed the bot in robots.txt three weeks ago and there are zero OAI-SearchBot hits in your logs, something is wrong (CDN block, IP firewall, misconfigured allow rule).
    • Manual citation audits — pick 10 priority queries, run them in ChatGPT with the Search toggle on, log which domains get cited. Repeat weekly. A spreadsheet beats no tracking.
    • Bing position tracking — because ChatGPT pulls from the Bing index, Bing rankings are a leading indicator. If your Bing position drops, ChatGPT visibility drops behind it.

    The Practitioner Summary

    Ranking in ChatGPT in 2026 is not mysterious. It is a four-gate funnel: Bing index → OAI-SearchBot crawl access → retrieval into the candidate set → citation selection. Most sites fail at gate one (not indexed in Bing) or gate two (OAI-SearchBot blocked or not addressed). Sites that clear those two gates and write pages that answer the question fully, with schema and a 500–2,000-word range, will land in the 15% that get quoted.

    Treat ChatGPT Search like a separate search engine that happens to share an index with Bing. Optimize for the index. Allow the crawler. Write the page. The rest follows.

    Related on Tygart Media: AI citation monitoring · AI search funnel · how AI engines cite.

  • Claude Code Rate Limits Doubled: Pro vs Max Plan Guide

    Claude Code Rate Limits Doubled: Pro vs Max Plan Guide

    If you bought a Claude Code subscription in March or April and felt like you were hitting the 5-hour wall every single afternoon, you weren’t imagining it. Anthropic spent six months tightening Claude Code’s quotas — and then, over two weeks in May 2026, gave most of them back. The rate-limit math that drove plan-selection advice on the internet through April is now obsolete. Here’s what actually changed, what the numbers look like today, and how to think about Pro versus Max if you’re picking a plan this week.

    What Anthropic actually did

    Infographic with three panels: protect the service, fair share, and cost control explaining rate limits
    What Anthropic actually did to rate limits.

    On May 6, 2026, Anthropic doubled the 5-hour rate limits on Claude Code across every paid plan — Pro, Max 5x, Max 20x, Team Premium, and seat-based Enterprise. In the same announcement, they removed the peak-hour throttle that had been quietly halving available quota for Pro and Max users during weekday business hours. They also lifted API-side rate limits on the Opus tier.

    One week later, on May 13, 2026, they followed up with a 50% increase to the weekly cap across the same plans. Unlike the 5-hour change, that weekly bump carries an expiration date: July 13, 2026, unless extended. Treat it as a temporary boost, not a permanent feature.

    The trigger Anthropic pointed to is a deal that brings the full capacity of the Colossus 1 data center in Memphis online — over 300 megawatts and roughly 220,000 NVIDIA GPUs. That detail matters less than the practical one: capacity-driven throttling that had been the dominant constraint since late 2025 has loosened.

    The new numbers, by plan

    The shape of the plan ladder hasn’t changed — Pro at $20, Max 5x at $100, Max 20x at $200, Team Premium at $100/seat with a 5-seat minimum. What changed is what each tier actually delivers per window.

    • Pro ($20/mo): Roughly 90 prompts per 5-hour window now (up from a number that, in practice, was hovering around 45 once the peak-hour throttle kicked in). No peak penalty. Weekly cap is 50% higher through July 13.
    • Max 5x ($100/mo): Same doubled 5-hour window. Weekly Opus 4.7 budget moved from approximately 50 hours to approximately 75.
    • Max 20x ($200/mo): Doubled 5-hour window. Weekly Opus 4.7 budget moved from approximately 200 hours to approximately 300.
    • Team Premium ($100/seat/mo, annual; $125 monthly): Mirrors Max 5x quotas at the seat level. 5-seat minimum still applies.

    Two numbers that haven’t changed: the API pay-as-you-go pricing for the underlying models (claude-sonnet-4-6 at roughly $3 per million input tokens and $15 per million output; claude-opus-4-7 at roughly $5 in and $25 out), and the existence of the weekly cap itself. The weekly cap is still the thing that kills Max users mid-Friday.

    What this changes about plan selection

    Infographic ladder of Claude plans: Free, Pro, Max, Team, and Enterprise
    Plan selection after the rate-limit change.

    Most of the “which plan should I buy” guides written before May 6 over-recommend Max 5x because they were sizing it against artificially compressed Pro limits. With a doubled 5-hour cap and no peak throttle, Pro at $20 is now genuinely enough for a developer doing focused coding sessions a few hours a day — something that wasn’t reliably true a month ago.

    The Max 5x case still holds, but it’s narrower now. The honest test: if you regularly burn through your Pro 5-hour window before lunch, or if you run two or three concurrent Claude Code sessions on different repos, $100 still pays for itself. If you don’t, Pro will hold.

    Max 20x is increasingly a workflow choice rather than a quota choice. The doubled limits made Max 5x sufficient for almost every solo workflow I can describe. Where 20x still earns its price is multi-agent workflows, where a coordinator-and-workers pattern can burn three to seven times the tokens of a single-agent session because every teammate maintains its own context window.

    The hidden costs that didn’t change

    The rate-limit relief is real, but several gotchas that drove “Claude Code costs me more than I expected” complaints in Q1 are still live:

    • Set ANTHROPIC_API_KEY in your shell and Claude Code bills at API rates — your subscription is silently ignored. Unset it before launching the CLI if you’re on a plan.
    • Weekly caps count active processing time only. Idle browsing is free. Long-running tool calls and extended-thinking budgets aren’t.
    • Extended thinking is billed as output tokens. On Opus 4.7 that’s roughly $25 per million. Default thinking budgets of tens of thousands of tokens per request stack up fast on API.
    • MCP server output sits in context for the rest of the session. A “list the last 20 PRs” call can dump 8,000 tokens of metadata that you’ll re-pay for on every subsequent turn until the conversation rolls over.

    If you were running into the 5-hour wall and assumed it was a usage problem, check whether one of those four is actually the cause before you upgrade.

    What to do this week

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    What to do this week.

    If you’re on Pro and were considering Max 5x, wait two weeks. The new Pro ceiling is high enough that the upgrade decision now needs different evidence than it did in April.

    If you’re already on Max 5x and felt squeezed, the May 13 weekly bump should give you breathing room — but mark July 13 on your calendar. If the temporary 50% increase isn’t extended, the squeeze comes back.

    If you’re picking a plan from scratch today: start on Pro. The doubled limits are real, the peak-hour penalty is gone, and the upgrade path to Max stays open with no friction. Buy quota when you’ve measured that you need it, not before.

    The model versions to use

    For anyone writing the API string into a script this week: flagship is claude-opus-4-7, workhorse is claude-sonnet-4-6, fast tier is claude-haiku-4-5-20251001. Pull from docs.anthropic.com/en/docs/about-claude/models before shipping anything — the version strings have moved twice already this year and they’ll move again.

    Related on Tygart Media: Claude Code billing · Claude Pro vs Max · Claude Code getting started.

  • Restoration Google LSA Changes: Verified Badge & Disputes

    Restoration Google LSA Changes: Verified Badge & Disputes

    If you have been running Google Local Services Ads (LSAs) for your restoration company for more than a year, the platform you’re managing today is not the one you signed up for. Two changes that landed in late 2025 quietly rewrote the economics of LSAs for restoration contractors — and most owners I talk to are still operating on outdated assumptions. The badge you bragged about is gone. The dispute process you relied on to claw back bad leads is gone. And the insurance trap that can silently kill your campaign is bigger than ever. Here is what actually changed and what you should do about it.

    The badge consolidation: “Google Guaranteed” is now “Google Verified”

    Three cards: verify business facts, respond to disputes fast, protect with job quality
    Badge renamed — ops discipline did not get easier.

    Effective October 20, 2025, Google folded its three trust badges — “Google Guaranteed,” “Google Screened,” and “License Verified by Google” — into a single unified “Google Verified” blue checkmark. For restoration owners who spent months getting the green Google Guaranteed badge and then put it on their trucks and websites, this matters. The badge you earned still exists, it just looks different and means something slightly different now.

    The verification requirements themselves haven’t loosened. You still pass a background check (Google runs this free through its partner Evident), and Google still verifies your license and insurance. Reported approval timelines run roughly three to four weeks once your documents are submitted — budget for that lag if you’re launching into a busy season.

    The money-back guarantee is dead — and that changes your pitch

    Here’s the change almost nobody talks about: the consumer money-back guarantee that was the whole point of the “Google Guaranteed” name was discontinued on November 7, 2025. Under the old program, if a customer was unhappy with a job booked through LSAs, Google would reimburse them up to a lifetime cap. That backstop is gone.

    Why should a restoration owner care? Because if your sales process or your website copy still leans on “we’re backed by Google’s money-back guarantee,” you are now making a claim that is no longer true. Audit your marketing materials. The badge now signals verification — that you are who you say you are, licensed and insured — not a satisfaction guarantee. That’s a meaningful difference in how you should position it to a homeowner who just had a pipe burst.

    The bigger story: manual lead disputes are gone

    This is the change that hits your wallet directly. For years, the LSA model let restoration contractors manually dispute junk leads — wrong number, spam, a caller looking for a service you don’t offer, a job outside your service area — and recover a meaningful share of those charges. Reports from contractors who worked the old system suggest manual disputes recovered credits on a solid majority of flagged bad leads when documented well.

    Google removed manual disputes in 2024 and replaced them with an automated credit system. Here’s how it works now: Google’s machine learning reviews leads, typically within about 72 hours of being charged, and automatically applies credits for leads it deems invalid, with credits generally appearing within roughly 30 days. You no longer build a case and submit it. The algorithm decides.

    Two limitations matter enormously for restoration:

    • “Job type not serviced” and “geo not serviced” leads are no longer creditable. If a caller wants mold remediation and you only do water mitigation, or the job is two counties away, Google will not credit that charge anymore. Restoration owners across the home-services space have reported receiving out-of-area and out-of-category leads with no recourse — and that’s now baked into the system, not a glitch.
    • The automated system is reportedly less generous. Practitioner estimates put the current automated credit rate well below what manual disputes used to recover. You will eat more bad-lead cost than you used to. Plan your cost-per-acquisition math accordingly.

    The one lever you still have: rate every lead

    Side-by-side of metrics to track versus vanity metrics to ignore
    The one lever you still have: rate every lead honestly.

    The “Rate this lead” feedback tool in your LSA dashboard is not a customer-satisfaction survey — it’s the primary input the automated credit engine uses. Marking a lead as “Very dissatisfied” with a specific, accurate reason is reportedly the most reliable way to nudge a credit. The discipline here is operational: whoever answers your LSA calls needs a standing instruction to rate every single lead the same day, with notes. If you’re not rating leads, you’ve handed the algorithm zero signal and you’re leaving credits on the table.

    The silent campaign-killer: your insurance certificate

    Here is the trap that takes down more restoration LSA accounts than bad creative ever will. Google periodically re-checks the license and insurance on file in your LSA account. When your general liability policy renews and you don’t upload the new certificate, Google can pause your ads automatically — no warning email that most owners notice, no grace period you can count on. For a restoration company, an unexplained pause during storm season is real revenue walking out the door.

    The fix is trivial and free: set a calendar reminder for two weeks before your GL policy renews each year to upload the fresh certificate of insurance into your LSA account. This single recurring task prevents the most common avoidable outage in the channel.

    What this costs you in restoration

    For context on the stakes: water damage restoration sits at the expensive end of LSAs because the jobs are big and contractors bid the channel up. Reported cost-per-lead figures for water damage restoration commonly land in roughly the $75–$200 range depending on market competition, with some sources citing $300+ per call in the most aggressive markets. Cost per acquired job is reported in the rough range of $200–$800. With restoration margins what they are, those numbers can still pencil out — but only if you’re not silently absorbing uncreditable junk leads and only if your account never goes dark over a lapsed insurance cert. The platform changes above all push in the same direction: the margin of error on LSA management got thinner in late 2025.

    The bottom line

    White restoration work van with ladder rack parked at a suburban jobsite curb
    Bottom line: LSA is a system, not a set-and-forget badge.

    If you run LSAs for a restoration company, do three things this week. First, scrub any “money-back guarantee” language from your marketing — it’s no longer accurate. Second, make daily lead-rating a non-negotiable task for whoever fields your LSA calls, because rating is now your only real influence over credits. Third, put a recurring two-weeks-before-renewal reminder on the calendar to update your insurance certificate. None of these cost a dollar, and together they protect the most expensive lead channel in your marketing budget from the changes Google made while you weren’t watching.

  • Verify llms.txt: How to Check Server Logs for AI Crawlers

    Verify llms.txt: How to Check Server Logs for AI Crawlers

    You shipped an llms.txt file. You curated the links, you paired it with robots.txt, you validated the format. Now answer the only question that matters: is anything actually requesting it? Most site owners never check — and the data from 2026 suggests the honest answer, for most domains, is “almost nothing.” This is the verification step that turns llms.txt from an act of faith into a measurable signal. Here is how to read your own server logs and find out exactly what is fetching the file you published.

    Why verification matters more than the file itself

    Three cards for Google cautious, Bing speed, OpenAI aggressive crawl styles
    Why verification matters more than the file itself.

    The uncomfortable finding of the last year is that publishing llms.txt and benefiting from llms.txt are two different things. In OtterlyAI’s 90-day crawler study, only 0.1% of AI crawler requests touched /llms.txt at all — 84 requests out of 62,100 total AI bot visits — and the file received far fewer visits than the average content page (OtterlyAI GEO study). As of Q1 2026, no major AI company — OpenAI, Google, Anthropic, Meta, or Mistral — has publicly committed to reading or acting on llms.txt in production systems, though GPTBot does fetch the file occasionally (AEO Engine).

    That does not make the file worthless. It makes measurement the whole game. If you cannot tell whether a crawler ever requested the file, you cannot tell whether your time was wasted, whether a platform quietly started honoring it, or whether your file is returning a silent 404. Verification is the difference between strategy and superstition.

    The five-minute server-log check

    Four ranked rows of AI crawler fleets reading publisher content
    Five-minute server-log check.

    Every fetch of your llms.txt file leaves a row in your access log. The job is to isolate requests to that path, then filter by the user-agents that belong to AI systems. On any server with standard combined-format Apache or Nginx logs, this one-liner does the first pass:

    grep -E "/llms(-full)?\.txt" /var/log/nginx/access.log | \
      grep -E -i "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Google-Extended|Google-CloudVertexBot|Amazonbot|CCBot|Applebot|meta-externalagent|MistralAI-User|bingbot"

    The first grep narrows to requests for llms.txt or llms-full.txt. The second filters to the known AI crawler user-agent strings documented across 2026 reference work (No Hacks AI User-Agent Landscape 2026; Momentic crawler list). Each surviving line tells you three things: which bot, what time, and the HTTP status code it received.

    That status code is the part people skip. A 200 means the bot got your file. A 404 means you have been congratulating yourself over a file the crawler never actually reached — a misconfigured path, a redirect loop, or a build step that drops the file on deploy. A 301 or 302 means it is being redirected, and not every crawler follows redirects for this path. Read the status column before you read anything else.

    Turn the raw hits into a monthly cadence table

    One grep tells you whether the file is reachable. To know whether anything is changing, you need the same query run on a schedule and counted by bot. Extend the pipeline to a count:

    grep -E "/llms(-full)?\.txt" /var/log/nginx/access.log* | \
      grep -E -i -o "GPTBot|ClaudeBot|PerplexityBot|Google-Extended|bingbot|Amazonbot|CCBot|Applebot" | \
      sort | uniq -c | sort -rn

    This produces a leaderboard of which AI user-agents requested your llms.txt across all retained logs. Capture that number on the first of each month and you have a cadence series. The signal you are watching for is not the absolute count — it will be small — but the direction: a bot that appears for the first time, a bot whose hit count jumps, or a bot that goes silent. Those inflection points are the leading indicators that a platform has changed how it treats the file.

    What you see in the logWhat it meansAction
    No requests to /llms.txt at allFile may be unreachable, or simply not yet fetched — both are commonRequest the URL yourself; confirm a clean 200 before assuming neglect
    200 from GPTBot, low frequencyConsistent with reported behavior — GPTBot fetches occasionallyLog the cadence; treat as baseline, not a ranking signal
    404 or 301 on the pathCrawler is not getting the file you think you publishedFix the path/redirect today — this is a silent failure
    A new bot appears month-over-monthA platform may have started fetching the fileNote the date; correlate with any citation or referral changes

    Cross-check against your content fetches

    The llms.txt hit count means little in isolation. Compare it against how often the same bots fetch your actual content pages. If GPTBot pulls forty content URLs a day and never touches llms.txt, the file is not part of how that crawler discovers you — your content’s own structure and internal linking are doing the work. The practical monitoring approach documented for 2026 is exactly this: a server-log dashboard built against the major user-agents, watching cadence and path-preference shifts month over month (Digital Applied 30-day log study). The same study notes distinct personalities worth knowing — GPTBot crawls more aggressively than most assume, ClaudeBot is more patient than its volume suggests, and PerplexityBot is quieter than its share-of-voice would predict.

    What to do with the answer

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    What to do with the answer.

    If your logs show the file is reachable and occasionally fetched, you are in the normal range for 2026 — keep the file current and keep measuring. If they show a 404, you found a real bug that no amount of curation would have fixed. And if they show a brand-new bot starting to request the path, you have spotted a platform behavior change before the blog posts catch up to it. That last case is the entire payoff: the practitioners who read their own logs will know the standard started mattering weeks before the ones who only read about it. Verification is not the boring final step of an llms.txt rollout. On a standard that nobody has formally committed to honoring yet, it is the only step that produces evidence instead of hope.

    Related on Tygart Media: AI crawler experiment · GEO tactics · Bing Webmaster AI tab.

  • Claude Code MCP Scopes: Mastering the –scope Flag

    Claude Code MCP Scopes: Mastering the –scope Flag

    Everyone teaches you how to add an MCP server to Claude Code. Almost nobody teaches you where to add it — and that one decision, the scope flag, is the difference between a clean team setup and three engineers debugging why the same server works on one machine and not another. I’ve watched it happen. The fix is always the same: someone added a server at the wrong scope.

    If you run claude mcp add without thinking about scope, Claude Code makes the choice for you. It defaults to local. That’s fine for a throwaway experiment and wrong for almost everything else.

    The three scopes, and what each one actually controls

    Flow from app/IDE through MCP to servers and data APIs
    The three scopes, and what each one actually controls.

    Claude Code stores MCP server configurations in three places, and the --scope flag decides which one you’re writing to.

    Local scope (the default) writes the server config into your personal settings, keyed to the current project path, inside ~/.claude.json. Nobody else sees it. It doesn’t get committed. Open the same repo on your laptop at home and the server isn’t there. This is the scope you want for a one-off — a database you’re poking at this afternoon, a server you’re still deciding whether to keep.

    Project scope writes to a .mcp.json file at the root of the repository. You commit that file to git. Everyone who clones the repo gets the same servers, configured the same way. This is the scope that makes MCP a team decision instead of a personal one — and it’s the one most people skip because the default never points them at it.

    User scope writes to your global config so the server is available in every project you open, regardless of which repo you’re in. This is for the handful of servers you genuinely use everywhere — a documentation search server, a personal notes tool — not for anything project-specific.

    The mental model I use: local is “me, here, now.” Project is “anyone on this repo.” User is “me, everywhere.” If you can articulate which of those three sentences describes the server, you know the flag.

    The command, written three ways

    Five stacked panels of daily Claude Code command habits
    The command, written three ways.

    Same server, three scopes. The only thing that changes is the flag.

    # Local — default, personal, not committed
    claude mcp add --transport stdio my-db -- npx -y @some/db-mcp-server
    
    # Project — shared via .mcp.json, commit to git
    claude mcp add --scope project --transport stdio my-db -- npx -y @some/db-mcp-server
    
    # User — available in every project you open
    claude mcp add --scope user --transport stdio my-db -- npx -y @some/db-mcp-server

    Verify what’s connected and where it came from with claude mcp list. If a teammate reports a server “isn’t working” and yours is fine, this is the first command to run on both machines — the discrepancy is almost always a scope mismatch, not a broken server.

    The .mcp.json pattern that actually pays off

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    The .mcp.json pattern that actually pays off.

    Here’s the workflow that turns this from trivia into leverage. When you onboard a repo that the whole team uses, you decide once which MCP servers belong to that codebase — the Postgres server pointed at the dev database, the issue tracker, whatever the repo’s daily work requires — and you add them all at project scope. The resulting .mcp.json looks like this:

    {
      "mcpServers": {
        "postgres": {
          "command": "npx",
          "args": ["-y", "@some/postgres-mcp-server", "postgresql://localhost/devdb"]
        },
        "linear": {
          "type": "http",
          "url": "https://mcp.linear.app/mcp"
        }
      }
    }

    Commit it. Now a new hire clones the repo, opens Claude Code, and the agent already knows how to query the dev database and read tickets — no setup doc, no Slack thread asking “wait, how do I connect the database again.” The repo carries its own integration surface.

    One safety detail worth knowing: when Claude Code encounters project-scoped servers from a .mcp.json it didn’t write, it asks you to approve them before they run. That prompt exists because a committed config file is, technically, code other people can put on your machine. Read what you’re approving — the same way you’d read a package.json script before running it.

    Where this bites people

    Three failure modes I see repeatedly. First: adding a server at local scope, then wondering why it vanished on a different machine — local is path-and-machine specific, that’s the design. Second: putting a secret directly into .mcp.json and committing it to a public repo. Don’t. Reference an environment variable in the config and keep the actual token out of git. Third: piling everything into user scope so every project loads servers it doesn’t need, which bloats the context the agent has to reason over and slows routing when you have many tools connected.

    The cost angle, since it’s a fair question: scoping itself costs nothing. But every connected MCP server adds its tool definitions to the model’s context on each turn. With Sonnet 4.6 as the workhorse model, a lean per-project tool set is faster and cheaper than a kitchen-sink user-scope config you never pruned. Scope discipline is, indirectly, token discipline.

    The rule that replaces all of this

    Before you run claude mcp add, finish this sentence: “This server should be available to ___.” If the answer is “just me, just here” — local. If it’s “anyone working in this repo” — project, commit the file. If it’s “me, in everything I do” — user. The flag follows from the sentence. Get that habit, and the entire class of “works on my machine” MCP bugs disappears from your team’s life.

  • AI Site Auditing: Catching Silent Failures in Workflows

    AI Site Auditing: Catching Silent Failures in Workflows

    There is a class of problem in an AI-native operation that is invisible to every individual surface and obvious to the audit layer that sits across them. The site looks healthy. The dashboard is green. And the body of work has stopped compounding.

    The Green Dashboard Trap

    Seven cards naming common AI chatbot failure modes
    The green dashboard trap.

    In modern serverless architectures and agentic pipelines, we are trained to monitor local execution outputs. We build alerts for 500 errors, set up uptime pings, and watch cron job completions. If the terminal or console returns a successful exit code, we assume the system is functioning.

    But in generative workflows, a script can run perfectly, parse without throwing syntax errors, make successful API calls, and still produce completely empty pages or silent failures (such as duplicating pages with -2 slugs). The surface looks pristine, but the structural value is eroding.

    Why Isolated Auditing is Essential

    Five security domains: identity, data, code governance, audit, agents
    Why isolated auditing is essential.

    Individual execution environments (like a Claude Code terminal instance or an Antigravity background task) only know what is in their immediate input context. They do not know if the overall sitemap is bloated, if search engine canonical flags are misconfigured, or if previous runs created redundant resources. They check the box for their specific task and exit.

    An audit plane sits above these execution agents. It doesn’t write code or publish content. Instead, it continuously queries the outputs of the entire operation, testing for anomalies like:

    • Thin Content: Published pages that lack text bodies.
    • Taxonomy Decay: Articles published without tags or nested in default categories.
    • Asset Duplication: Identical titles or slugs created due to syncing conflicts.

    Implementing a Two-Plane Architecture

    Three stacked layers: chat UI, tools, agent runtime
    Implementing a two-plane architecture.

    To prevent silent failure in portfolio management, operators must separate the Execution Plane from the Control & Auditing Plane. Notion or similar databases act as the control plane where human instructions and data states live. Google Cloud Run or local CLI tools act as compute. But a third independent auditor loop must actively crawl, assert, and report on the final state of the live web asset.

    “When trust is earned in evidence rather than asserted by success logs, you stop running broken systems that look perfectly healthy.”

    The audit sees what the site cannot, because the site only knows what it is, not what it has repeatedly become.

    Related on Tygart Media: verify llms.txt in logs · AI crawler experiment · WordPress SEO audit.

  • Claude Code vs Cursor: Token Efficiency & Agent Teams

    Claude Code vs Cursor: Token Efficiency & Agent Teams

    I’ve been running both Claude Code and Cursor on the same codebases for the last eight months. Not as a reviewer — as someone who has to actually ship features in both tools and watch the credit meter tick. Here is what the comparison actually looks like in May 2026, after Cursor’s credit overhaul, after Claude Opus 4.7, and after Claude Code’s agent teams went GA.

    The Real Pricing Picture

    Workshop fuel gauge and metal tokens pouring into an API hopper, metaphor for pay-per-token pricing
    The real pricing picture — stale-proof.

    The headline subscription numbers are nearly identical: Claude Pro at $20/month, Cursor Pro at $20/month. That’s where the similarity ends.

    Cursor’s Pro tier in 2026 ships with unlimited “Auto” mode requests plus a $20 credit pool for premium models. Pro+ is $60/month with roughly 3x credits and background agents. Ultra is $200/month at 20x usage. Hobby is still free with limited requests. Teams is $40/user/month.

    Claude Code on the Pro plan gets you Sonnet-tier usage with quota limits. Max at $100/month unlocks Opus access and 5x the usage envelope. The team plan for Claude Code is where the real spread shows: Anthropic’s team pricing on Claude Code lands materially higher than Cursor Teams for a comparable seat count. If you’re a 10-person team buying the most generous tier of each, you’re looking at roughly 3x more for Claude Code.

    For solo developers, the cost is a wash at the entry tier. The decision is not about money — it’s about how each tool burns tokens.

    Token Efficiency Is the Hidden Variable

    This is the number I wish I had known a year ago: independent benchmarking through 2026 has Claude Code using roughly 5.5x fewer tokens than Cursor on identical tasks. Not 5.5% — five and a half times fewer.

    The why matters. Cursor’s agent loop tends to re-read files, re-include context, and verify intermediate steps by stuffing prior turns back into the prompt. Claude Code’s CLI architecture leans on a tighter context budget by default, and on Opus 4.7 the model itself is doing more work per token. When you’re paying by credit (Cursor) and your power-user-hours start adding up, that ratio is the difference between a $60 month and a $200 month.

    The honest counterpoint: Cursor’s median completion time on simple, single-file edits is roughly 12% faster than Claude Code. If you live in the find-and-fix-a-typo loop, Cursor’s IDE integration genuinely wins.

    Where Claude Code Wins

    Side-by-side cards defining what Claude Code is and is not
    Where Claude Code wins.

    The 1M token context window is now generally available on Claude Opus 4.6, Opus 4.7, and Sonnet 4.6, at standard per-token pricing with no long-context surcharge. A 900,000-token request costs the same per-token rate as a 9,000-token one. For codebases that need to be understood holistically — monorepos, large migrations, anything where “ctrl-F across 200 files” is part of the problem — this is the single most consequential capability difference in 2026.

    Agent teams went past experimental in 2026 with Claude Code v2.1.32 and the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 flag. The team-lead pattern — one Claude session coordinating teammates who can message each other, share a task list with dependencies, and lock files — is a genuinely different primitive than Cursor’s background agents. The cost is real: agent teams use approximately 7x the tokens of a single session in plan mode. The benefit is also real: the work that previously needed a human program manager now runs unattended.

    On full-feature implementation tasks — the kind where a benchmark measures end-to-end PR shipment, not single edits — Claude Code was roughly 18% faster on median wall-clock time. Opus 4.7 specifically lifted resolution on a 93-task coding benchmark by 13% over Opus 4.6, including four tasks that neither Opus 4.6 nor Sonnet 4.6 could solve.

    Where Cursor Wins

    Five stacked panels of daily Claude Code command habits
    Where Cursor wins.

    The editor. This is not a small thing. Cursor is still a VS Code fork that evolved into an agent workbench. The integrated diff view, the multi-file edit preview, the in-line ghost text completions, the model picker in the corner — none of that exists in Claude Code, which lives in a terminal pane. If you have a strong opinion about your IDE and you want AI features welded inside it, Cursor is the answer.

    Cloud agents on Cursor Pro and above run AI tasks in isolated cloud VMs with no access to your local machine. The use case — fire off a refactor and walk away from your laptop — is well-served. The catch: background agents always use MAX mode, which adds a 20% surcharge on credit cost, and a single agent run on a 50,000-line codebase can consume around 22.5% of a Pro plan’s monthly credits. One bad day of agent runs eats your month.

    Model variety is also a Cursor advantage. You can route a task to a non-Anthropic model when the situation calls for it. Claude Code is Claude all the way down.

    What I Actually Run

    Both. For $40/month at the Pro tier on each, I get the most powerful AI coding setup available in 2026. Claude Code handles the long-context architectural work, the cross-cutting refactors, the agent-team orchestration where one Claude is doing program management and three teammates are touching different services. Cursor handles the IDE work — the small-bore edits, the in-line completions, the moments where I want to see a diff hover above the line I just changed.

    If forced to pick one, the answer depends on the work. Heavy backend, large codebases, multi-agent workflows: Claude Code. UI-heavy, single-file iteration, “I just want my editor to be smarter”: Cursor.

    The Honest Limitation

    Claude Code on a team plan is genuinely expensive at scale. A 10-person team running Claude Code at the team-equivalent tier is roughly 3x the Cursor Teams equivalent. If you’re cost-sensitive at headcount, that math may decide the question regardless of capability. The token-efficiency advantage helps Claude Code claw back some of that on per-task economics, but the subscription line item is the line item.

    The other honest limitation: model versions move fast. As of May 26, 2026, the current Anthropic lineup is Claude Opus 4.7 (flagship), Claude Sonnet 4.6 (workhorse), and Claude Haiku 4.5. Any comparison written more than a quarter ago is already partially wrong on the model column. Read pricing pages, not blog posts, when you’re committing budget.

    The Bottom Line

    Cursor wins on editor experience, model variety, and team subscription cost. Claude Code wins on token efficiency, context window economics, agent-team primitives, and Opus 4.7’s raw coding capability on hard tasks. If you’re optimizing for one tool, pick the one that matches the bulk of your work. If you can afford $40/month, run both — and pay attention to which one you actually open first in the morning. That’s your real answer.