organic-os

Category: Uncategorized

  • Automating a Content Calendar Without Losing Judgment

    Automating a Content Calendar Without Losing Judgment

    Automating a content calendar means automating the admin around publishing, not the decisions that make a piece worth publishing: scheduling, routing drafts through fixed stages, running the same checks every time, and keeping a dated record of what happened. The actual judgment calls — what to write, whether a claim is verified, whether a draft reads honestly — stay with a person, or with a single standing approval a person gave on purpose. This site runs on exactly that split. One human approval from September 2 covers an 80-topic batch; 52 of those topics had published by the time this one went out, each through the same six-stage pipeline, and at least five of those runs have hit a real bug along the way. None of the bugs were in the writing. All of them were in the plumbing.

    Most advice on automating a content calendar stops at the tooling question: which app, which database, which trigger. The more useful question is which specific steps are safe to hand off and which ones need a person reading the actual output before it goes live. I looked at live search results for this exact framing before writing anything here, and the pattern across sources is consistent: automation earns its keep on repetitive, rule-based, easily-reviewed work — reminders, status-triggered routing, drafting support, scheduling — while anything touching brand voice, factual accuracy, or strategic priority stays a human checkpoint. One source frames it as a line-producer-and-showrunner split. That matches how this pipeline is actually built, not as a design choice made in the abstract but as something that got forced into shape by real failures, which is the more useful story to tell.

    The process, named stage by stage

    Every piece that ships here goes through the same six named stages: research, draft, QA, editor, a featured-image generation step, then publish. Each stage writes its output to a dated folder — a research pack, a QA log, editor notes, the image and payload files — so the record of how a specific piece got made is as persistent as the piece itself. That structure is what automated content operations: what to hand off, what to keep argues for directly: a calendar only becomes automatable once it lives in a structured, inspectable format rather than a spreadsheet or a verbal plan, because the structure is what makes a later stage able to check an earlier one’s work.

    What makes this a calendar rather than a one-off script is the batch mechanism sitting above those six stages. Instead of approving each post individually, 80 topics were approved once, in a single decision, with each one shipping on its own day without asking again. That single decision is explicitly revocable — a status change or an emptied queue stops the whole batch — which matters more than it sounds like it should, because a standing approval that cannot be revoked isn’t automation with judgment attached, it’s just a commitment made once and never revisited.

    What is automated versus what a human still judges

    The honest answer is that “auto-approved” does not mean “unchecked.” Three things from this exact batch’s own run history show where judgment still sits even inside an automated calendar. First, an automated label-leak checker once flagged two false positives — a code snippet demonstrating an escape character, and a quoted historical reference to a label that had leaked in an earlier post — and both were investigated by reading the actual surrounding text rather than mechanically edited to satisfy the checker. Second, a real defect (a featured image reference saved as empty because the upload hadn’t finished yet) was caught on review before the post was ever created, not patched after the fact. Third, every single publish re-fetches the live post afterward and diffs the saved content against what was submitted, rather than trusting the create response — that verification step is itself a designed-in judgment checkpoint, the same discipline why your SEO automation needs an audit trail argues should exist anywhere automation is allowed to touch a live site. None of this is the system catching itself; it’s the system being built to make catching things possible, which is a different claim and a smaller one worth stating precisely.

    The same split shows up in what the pipeline is deliberately not allowed to do. The WordPress credential this pipeline runs under can create, edit, and publish posts, but it cannot purge a caching layer that needs broader site permissions — a boundary that has caused real, repeated friction, and one that stays in place on purpose rather than getting “fixed” by widening the credential. Scoping automation to only what a task needs, even when that scoping costs convenience, is the same argument made in guardrails for AI agents that touch your website: a guardrail that gets removed the first time it’s inconvenient was never really a guardrail.

    Our own before and after

    The clearest before-and-after in this pipeline’s own history is a formatting failure from earlier this year, kept on record rather than quietly fixed and forgotten. Every one of the first seven posts this pipeline produced opened with a visible “In short:” label inside the answer section, and no custom excerpt had been set, so WordPress’s automatic excerpt pulled that exact label text into every listing page a reader would see before clicking through. The fix was specific: a formatting contract was added to the production prompt requiring plain reader-facing prose with no label text anywhere in the body, and a clean excerpt set on every post going forward. All seven live posts were repaired the same day the problem was found, and the rule has been checked on every post since.

    A second, related failure is why this pipeline now checks the rendered page rather than trusting an API response. One post went live with eighteen Gutenberg block comments that had been accidentally backslash-escaped during a shell command, which WordPress could not parse — so they rendered as literal garbage text on the actual page, while a content check run against the raw API data looked completely clean. That gap between “the data looks right” and “the page looks right” is why render verification exists as its own separate step now, checked against the live HTML and not the stored content. A third incident, smaller but telling, is a single approved brief that silently dropped out of the queue for weeks because one unescaped character broke its file’s frontmatter — not a crash anyone saw, just an item that quietly stopped existing to the system until a full queue rebuild happened to surface it. Version-controlling every one of these files, the same practice version control for SEO: diffing your own site makes the case for, is what let each of these three incidents be found, dated, and fixed instead of just suspected.

    How to tell if the process is helping

    A calendar that reliably ships posts is not automatically a calendar that is working — reliability is a claim about the process, not about whether readers or search engines care about the output, and keeping those two claims separate is the same discipline this site’s own measurement posts insist on for any other SEO metric. The way to check this specific page honestly is the same falsifiability test applied to every other piece in this batch: if, sixty days after this publishes, Search Console still shows zero impressions for any query containing its primary keyword terms, despite the page being indexed, the piece did not work and that should be reported plainly rather than dropped from the record. The baseline to check that against is already set: as of today, none of the fifty highest-impression search queries hitting this site contain “automate” and “content calendar” together or in any close variant, which is exactly the clean starting point that test requires — not a projection of what will happen, just a reliable fact about where this page starts from before any answer appears.

    What I can say with more confidence, because it is a closed incident rather than a prediction, is that the specific defects named above have not recurred in the forty-six-plus days and roughly fifty posts since the formatting and render-verification contracts were added — every run since has logged a pass against both checks, not a silent skip. That is a narrow claim about two specific, previously-broken gates, not a broader claim that the whole process is “working.” Judging whether an automated content calendar is helping means tracking both kinds of evidence at once: whether the gates that exist because something broke are still holding, and whether the output they protect is actually earning attention once it ships.

    Shivaa Tripathi runs organic-os, an experiment in publishing SEO and AEO work with the research and verification shown rather than asserted.

  • Simple Anomaly Detection for Organic Metrics

    Simple Anomaly Detection for Organic Metrics

    SEO anomaly detection, done simply, means comparing a short recent window of your own Search Console and Analytics data against a defined baseline window, and only calling something an anomaly if it holds for multiple days rather than reverting after one. Applied to this site’s own 138-day Search Console window, the real numbers are 790 impressions, 1 click, a 0.127% click-through rate, and 55 of 138 days — 39.9% — with zero impressions at all. The one clear anomaly in that window is a real multi-day step change in late August, not a one-day spike, and it is reported here with the same noise floor applied to every other number in this piece.

    Most anomaly-detection advice stays at the level of “watch for unusual spikes or drops.” I checked the live search results for this exact topic before writing anything here, and the more specific version of that advice holds up: anomalies are deviations outside an expected band of normal variation, the common causes are sudden drops from indexing or tracking breakage and sudden spikes from bot traffic or seasonal demand, and the standard fix for telling a real anomaly from noise is cross-referencing Search Console with Analytics and defining a baseline before calling anything unusual. This piece runs that method against this site’s own numbers, including the ones that don’t flatter it.

    The method, step by step

    Two data pulls do the actual work. The first groups Search Console data by date across a wide window, which shows whether visibility exists at all on a given day and how it moves over time. The second groups the same window by query, which shows which specific search terms are producing impressions and whether a target keyword is showing up anywhere yet. A third pull, Analytics engagement data for a comparable period, checks whether any traffic arriving is actually engaging or just bouncing. Running all three as raw data pulled by script, rather than reading numbers off a dashboard screenshot, is the same discipline behind building an SEO dashboard from APIs, not screenshots: a number computed the same way twice is checkable, and a number eyeballed off a chart usually isn’t.

    Once the three pulls are in hand, pick a baseline window before looking for anomalies, not after — picking the baseline after seeing the data is how a real pattern gets fitted to a story instead of tested against one. Then apply a short persistence test to anything that looks interesting: did the change hold for several days in a row, or was it a single-day blip? Is there a plausible cause — new content, a new link, an indexing change — or no corresponding event at all? A genuine step change holds at an elevated level across multiple consecutive days. A blip reverts immediately. That distinction is the entire method; everything else is just bookkeeping.

    This site’s real numbers right now

    The by-date pull covers June 1 through October 16, 2026 — 138 days, pulled site-wide rather than filtered to this specific page, since a brand-new URL has no history of its own yet. Across that window: 790 total impressions, 1 total click, and a site-wide click-through rate of 0.127%. Fifty-five of the 138 days — 39.9% of the window — show zero impressions at all, and the window opens with zero impressions straight through to July 18.

    The only click anywhere in these 138 days landed on September 9: one click on five impressions, a 20% click-through rate, at an average position of 5.8. The clearest anomaly in the dataset sits a couple of weeks earlier. Across the seven days from August 19 through August 25, impressions averaged 1.14 per day. Starting August 26, that average jumped to 39.5 per day across six straight days — 34, 42, 37, 39, 51, then 34 — before settling to a lower, still-elevated level afterward. Six consecutive days above the baseline is what makes that a step change worth naming rather than a blip worth ignoring, the exact persistence test described in telling SEO signal from noise on a small site.

    The by-query pull for the same window shows a gap the by-date view can’t: every single query row carries zero clicks, the single highest-impression query is “how to add canonical tag in the header of wordpress?” at 20 impressions and an average position of 18.95, and no query containing “anomaly detection” or a close variant appears anywhere in the fifty rows pulled — the keyword this exact page targets has not generated one measurable impression yet. That gap between impressions existing at all and a specific target keyword or click existing is the trap named directly in impressions but no clicks: what the data actually shows. The most recent seven days in this same pull (October 10 through 16) add up to 89 impressions and zero clicks — visibility continuing, conversion still absent.

    Reading results honestly

    One click in 138 days is not evidence of a trend; it is one data point with a sample size of one. Calling it “clicks are picking up” would be exactly the kind of overclaim this method exists to prevent. There is also a timing artifact worth naming: the most recent two or three days of any Search Console pull are provisional, because the data backfills and gets reclassified after the fact, a mechanism covered directly in why Search Console data lags and how to handle it. Reading a dip in the final day or two of a pull as a sudden drop would usually be reading a pull-timing artifact, not a real decline.

    The Analytics cross-check adds a second, harder signal. On every sampled day in this site’s engagement data, bounce rate reads 100% and engagement rate reads 0% — not an average, every single row in the sample. That is consistent with the Search Console pattern of impressions arriving without clicks: on the dates checked, visits that do land are not converting into engaged sessions. It does not prove why; it only states what the two data sources agree on.

    None of this means the numbers are too thin to use — it means the number worth reporting is a window-level aggregate, not a single day’s row read in isolation, and it means naming low-volume noise out loud instead of folding it into a cleaner-looking total. A single query sitting at one or two impressions in the 70s-to-90s position range is the kind of row SEO KPIs worth reporting (and three to drop) argues should be dropped from a report rather than included to pad it.

    What would falsify the conclusion

    This is a method meant to be checked again against this exact page, not a one-time read of a dashboard. The method described here is wrong for this specific page if, 60 days after it publishes, Search Console still shows zero impressions for any query containing the primary keyword terms, despite the page being indexed. That is the falsifiability condition this piece is written against, and it should be reported honestly rather than quietly dropped if it holds.

    Three checks are worth running before concluding the method itself failed:

    • Confirm the page is actually indexed before reading zero impressions as a failed result. A page that hasn’t been indexed yet will show zero rows for reasons that have nothing to do with anomaly detection.
    • Re-pull the same date range a few days later rather than trusting the most recent rows. As this piece’s own pull shows, the last two or three days in any window are provisional until Search Console finishes backfilling them.
    • Check whether any movement persisted for multiple days or reverted immediately. This site’s own late-August step change held for six straight days; a single-day spike that reverts the next day is the noise this method exists to filter out, not a signal worth reporting.

    Shivaa Tripathi runs organic-os, an experiment in publishing SEO and AEO work with the research and verification shown rather than asserted.

  • Measuring Content Decay Before It Costs You

    Measuring Content Decay Before It Costs You

    Content decay is the gradual decline in a page’s organic search performance after it has already ranked — fewer impressions, a softer average position, clicks that fade out — and it shows up over weeks, not in a single bad day. Measuring it on your own site means pulling Search Console by date across a wide window, checking whether a drop held for more than a day or two, and ruling out reporting lag before calling anything a decline. Run that check against this site’s own 138-day window and the honest number is 910 impressions, 6 clicks, a 0.659% click-through rate, and 38 of 138 days — 27.5% — with zero impressions at all. That is the floor this piece measures against, not a cherry-picked good stretch.

    I checked the live search results for “content decay SEO” before writing any of this. The term is used consistently to describe a slow fade in rankings, impressions, clicks, or engagement on a page that previously performed — never a sudden penalty. Documented causes include competitor pages overtaking a position, outdated information on the page itself, newer pages on the same site cannibalizing the same query, and shifting SERP features such as AI-generated overviews that cut clicks even while position holds steady. Every source treats detection the same way: a trend read over months from Search Console data, not a single day’s row. This piece runs that exact check against this site’s own numbers, including the ones that do not flatter it.

    The method, step by step

    Two pulls do the work. The first groups Search Console data by date across a wide window, which shows whether visibility exists on a given day and how that level moves over weeks. The second groups the same window by query, which shows which terms are producing the impressions and at what position. A by-date view can look stable while one query quietly disappears underneath it, and a by-query view cannot show the week-to-week movement that separates a real decline from a blip. Pulling both as raw data through a script, rather than reading a dashboard chart by eye, is the same discipline behind building an SEO dashboard from APIs, not screenshots: a number computed the same way twice is checkable, and a number eyeballed off a graph usually is not.

    Once both pulls are in hand, the actual decay test is a short set of questions applied to anything that looks like it is dropping: has the lower level held for multiple weeks, or is it one bad week bouncing back the next? Does the drop show up across several related queries, or only one? Is there a plausible explanation — a competitor’s new page, a stale claim on this page, a cannibalizing post published since — or no corresponding event at all? A genuine decay shows a sustained lower level across weeks with no single-day recovery. A blip reverts within days. Treating a blip as decay means rewriting a page that did not need it; treating real decay as noise means leaving a fading page untouched while something else quietly takes its place in the results.

    This site’s real numbers right now

    The by-date pull covers June 1 through October 16, 2026 — 138 days, with the 17th requested but not yet returned, a one-day gap that is lag rather than a drop (more on that below). Across that window: 910 total impressions, 6 total clicks, a site-wide click-through rate of 0.659%. Thirty-eight of the 138 days — 27.5% of the window — show zero impressions at all, including an unbroken 22-day stretch from June 1 through June 22 before this site had any visibility whatsoever on the queries it was being measured against. That zero-impression rate, not a single strong day, is the baseline any decay claim on this site has to be measured against.

    The clearest step change in this dataset sits in late August: impressions jumped from single digits to 41 on August 26 and held at an elevated level for six straight days — 42, 38, 42, 55, then 33 — before settling lower again. That multi-day persistence is what makes it a step change rather than a spike; a one-day jump that reverted immediately would have been noise, not signal. The most recent seven days in this pull, October 10 through 16, show 78 impressions and zero clicks (9, 7, 12, 11, 8, 13, 18) — visibility that is measurable but not converting. The last click anywhere in this window landed on September 17, which makes the stretch from September 17 to October 16 a 29-day run of impressions with no clicks at all, a pattern this site’s own impressions but no clicks: what the data actually shows argues should be read as a separate problem from visibility, not folded into it.

    The by-query pull for the same general period is a 50-row alphabetical sample rather than a ranked list, so it is useful here only for coverage, not for ranking which terms matter most. Every row in that sample shows zero clicks, and the highest-impression row — a question about adding a canonical tag in a WordPress header — sits at 20 impressions and position 18.95. Most rows carry one to three impressions at positions in the 50s through 90s, individually too thin to call a trend in either direction. That is exactly the kind of single-query noise SEO KPIs worth reporting (and three to drop) argues should be left out of a report rather than included to make a dashboard look fuller — and it is a reminder that a decay check needs a wide date window before it needs a long query list.

    Reading results honestly

    Two specific sources of noise showed up in pulling this exact data, and naming them matters more than smoothing them over. The first is timing: the most recent day or two of any Search Console pull is provisional, because the data backfills and gets reclassified after the fact. The mechanism is covered directly in why Search Console data lags and how to handle it, and it is the reason this piece’s own pull, requested through October 17, only actually returns complete rows through October 16. Reading that single missing day as a sudden drop in visibility would be the wrong read; it is a processing gap, not decay, and decay only means anything measured over weeks, never off the newest row in a pull.

    The second is a mismatch between data sources that is informative precisely because it does not line up. Checking this site’s GA4 engagement data over a comparable window, three days stand out sharply against a normal busy day of roughly 282 seconds average session duration: July 18 shows 3 sessions but a 1,198-second average duration, August 1 shows 2 sessions at 764 seconds, and August 7 shows a single session at 1,435 seconds — the most extreme of the three. Each pairs a tiny session count with an outsized duration, the usual signature of a bot or crawler session rather than a real reader. They are named here as likely artifacts, not cited as engagement, because folding them into a clean average would distort any baseline built from this window — the same noise-versus-signal discipline telling SEO signal from noise on a small site applies to Search Console data applies just as directly here.

    None of this means the numbers are too noisy to use. It means the number worth reporting is a window-level aggregate, re-checked after a few more days of backfill, rather than a single day’s row read in isolation — and it means saying out loud which days look like artifacts instead of quietly averaging them into a tidier-looking total.

    What would falsify the conclusion

    This is a method meant to be re-run, not a one-time read of a dashboard. The pre-publish baseline above shows zero rows in this site’s 50-query sample containing the term “content decay” or any variant of it — a clean starting point to check against later. If, 60 days after this page publishes, it still shows zero Search Console impressions for any query containing its primary keyword terms, despite being confirmed as indexed, the method described here did not work for this specific page, and that result should be reported rather than quietly dropped.

    Three checks are worth running before concluding the page itself is decaying:

    • Confirm the page is indexed before reading a drop as decay. A page that was de-indexed or never fully crawled will show falling or zero numbers for reasons that have nothing to do with search performance fading.
    • Re-pull the same date range a few days later rather than trusting the newest rows. As this piece’s own pull shows, the final day or two of any window is provisional until Search Console finishes backfilling it.
    • Check whether the lower level held for multiple weeks or reverted on its own. This site’s own August step change moved in the other direction and held for six days; real decay should show the same multi-week persistence before it gets treated as a problem worth fixing.

    Shivaa Tripathi runs organic-os, an experiment in publishing SEO and AEO work with the research and verification shown rather than asserted.

  • An AI Citation Audit You Can Run Monthly

    An AI Citation Audit You Can Run Monthly

    An AI citation audit is a repeatable check of whether answer engines reference your pages, run monthly with three free inputs: Google Search Console’s Generative AI performance report, a manual check of your Search Console AI inclusion setting, and a handful of your own target queries typed directly into ChatGPT, Perplexity, and Gemini with the results logged. None of the platforms publish a single “citation score,” and independent testing has found these tools get sourcing wrong at rates that make a one-time check unreliable, so the audit has to repeat on a schedule, not run once and get filed away.

    I went looking for an “AI citation audit” tool and found a lot of blog posts with that phrase in the title and not much underneath it — a checklist repeated from post to post, no links back to anything a platform actually publishes. So I built the checklist myself, from documentation I could fetch and read, plus the two independent studies that have actually tested citation accuracy with a transparent method. This is what’s verifiable today, including the parts that aren’t flattering.

    What the platform documentation actually says

    Two Google Search Console pages matter here, and a third data point comes from reading each AI platform’s own help documentation rather than secondary summaries of it.

    First, Search Console has a real report for this, and it’s narrower than people assume. The Generative AI performance report shows impressions, clicks, and average position for queries that triggered AI Overviews or AI Mode where your site appeared. Google’s own documentation flags a known data gap — an anomaly affecting August 13–17, 2025 — so treat the numbers as directionally useful rather than exhaustive. This report, not a separate AI-specific dashboard, is the starting point for any audit on a Google-indexed site.

    Second, there’s a setting worth checking before you conclude a page has a citation problem. The Search Generative AI control page documents two states: Include, the default, where content “may appear and be used to help ground AI-powered responses,” and Exclude, where it explicitly will not. The same page states that excluding a page “doesn’t act as a signal for ranking purposes elsewhere on Search” and doesn’t change participation in services like Merchant Center or Ads — it is a single, narrow toggle, not a visibility penalty that bleeds into other features. If a page you expect to see in AI Overviews never shows up, this setting is a five-minute thing to rule out before assuming the content itself is the issue.

    Third, OpenAI and Perplexity each describe their own mechanics in ways that double as audit instructions. OpenAI’s help documentation states that ChatGPT’s search results “may be incomplete, outdated, or otherwise inaccurate” and that no particular placement is promised — and separately confirms that OAI-SearchBot needs crawl access before a page is even eligible to be surfaced, which is a prerequisite worth checking before assuming the problem is citation behavior rather than crawl access. Perplexity’s help center describes its answers as built from “in-line, numbered citations” tied to retrieved sources, which means the audit step for Perplexity is literally running your target query and checking whether your domain appears among the numbered citations in the response. Neither platform publishes a lookup tool for this. You have to run the query and read the answer.

    What the independent evidence supports

    The reason a one-time check isn’t enough is that the tools themselves are inconsistent, and two independent studies from Columbia Journalism Review’s Tow Center for Digital Journalism measured that inconsistency directly rather than asserting it.

    In November 2024, researchers tested 200 direct quotes drawn from 20 publishers against ChatGPT Search and found it confidently wrong in 146 of those attempts — 73% of the sample. Results were inconsistent across repeated, identical prompts, meaning the same query could return a different, equally confident answer on a different run. OpenAI pushed back on the testing method as atypical of normal usage and said citation accuracy has since improved; I’m noting that pushback rather than treating the study as the final word on current performance.

    A March 2025 follow-up from the same researchers tested eight AI search tools — ChatGPT, Perplexity, Perplexity Pro, Grok 3, Grok 3 (Think), Copilot, Gemini, and DeepSearch — and found that collectively, more than 60% of answers were incorrect. The spread between tools was wide: Perplexity’s error rate was 37%, Grok 3’s was 94%. ChatGPT misidentified the source article in 134 of 200 tests and signaled low confidence only 15 times, never once declining to answer outright. Copilot was the single tool in the study that declined to answer more often than it answered incorrectly. And in a detail worth sitting with if you’re choosing a premium subscription expecting more reliable citations, the paid tiers — Perplexity Pro and Grok 3 — had higher error rates than their free counterparts, because they answered definitively more often instead of declining when uncertain.

    None of that is an argument against trying to earn AI citations. It’s an argument against trusting a single check, on a single tool, on a single day, as a verdict on whether your content “works” for AI answer engines.

    A practical monthly checklist

    This is the audit I’m actually running, repeated on a recurring monthly date so the comparison across months means something.

    • Pull the Generative AI performance report in Search Console and record impressions, clicks, and average position for your target pages — even if every number is zero. Zero is data, not an error state.
    • Confirm the Search Generative AI control setting is on Include for pages you want in AI Overviews, so you’re not auditing a page you’ve accidentally excluded.
    • Pick 5–10 real target queries and run each one manually in ChatGPT, Perplexity, and Gemini. Record whether your domain is cited, not cited, or cited incorrectly — a wrong citation is a different problem than no citation.
    • If a query returns a wrong or outdated citation, check whether the underlying page needs a direct, extractable opening paragraph; the pattern I use for that is covered in writing answer capsules.
    • Don’t add schema markup specifically chasing this. I checked the documentation on that question directly in structured data in the age of AI answers and separately in does schema markup help AI citations, and neither Google nor OpenAI documents a markup requirement for AI visibility.
    • If you want a longer-running measurement method rather than a monthly spot-check, see how to measure AI citations, which this audit is meant to complement, not replace.
    • Keep a dated log — a spreadsheet row per month is enough. The value of this audit is the trend across five or six months, not any single month’s result.

    If you’re trying to decide how much time this deserves relative to classic SEO work, the distinctions in GEO vs SEO vs AEO are worth reading first — AI citation visibility is a real, separate thing to track, but it sits alongside organic search work, not above it.

    The honest limits of current evidence

    I’ll report this site’s own numbers instead of skipping past them. In Google Analytics, across sessions from July 1 through October 5, 2026, no AI-assistant referrer domain — not chatgpt.com, not perplexity.ai, not claude.ai, not copilot.microsoft.com, not gemini.google.com — appears anywhere in the session-source breakdown. The top sources in that window were direct traffic at 171 sessions, Google search at 6, and GitHub referrals at 4. In Search Console, zero impressions showed up for any query containing the word “citation” over the same window. There is no existing AI-citation visibility on this site to report as a success story. This post is the starting point for the audit, not a recap of one that already worked.

    There are gaps in what any of the platforms will tell you, too. No platform publishes a general, cross-site citation-rate figure you could look up for your own domain — the numbers in the Tow Center studies are results from a specific test set of 200 quotes and a specific list of tools, not a live, ongoing score. Treat the two studies as dated findings about how these systems behaved when tested, not as a current, continuously updated grade. And excluding a page from AI features, per Google’s own documentation, doesn’t carry over as a ranking signal elsewhere — so if you’re troubleshooting a page that’s missing from AI Overviews, that setting is a thing to check and rule out, not a universal explanation for low AI visibility.

    So: run the checklist above once a month, log what you find including the zeros, and treat any single check — a good one or a bad one — as one data point in a series rather than a verdict.

    Shivaa Tripathi runs organic-os, an experiment in publishing SEO and AEO work with the research and verification shown rather than asserted.

  • Why Demand Gen Teams Should Report on Pipeline, Not MQLs

    If a demand gen team can hit its number without revenue moving, it is the wrong number. MQL counts are that kind of number: they can be inflated by loosening a scoring threshold or buying a content syndication list, and nobody outside marketing has to agree they mean anything. Qualified pipeline is harder to fake, because sales has to accept it and finance can see whether it closes. Demand gen teams should report on pipeline created per quarter, and treat MQLs as an internal diagnostic at most.

    Why MQL counts are so easy to game

    An MQL is not a fact about a buyer. It is a configuration choice. In most marketing platforms, the MQL stage is simply a field your own team defines: HubSpot’s lifecycle stage documentation describes an MQL as a contact your marketing team has decided is ready for sales, and notes that teams can customize the stages and set them automatically. That flexibility is useful, but it means the definition of the metric lives entirely inside the team being measured by it.

    The predictable failure modes follow:

    • Lower the lead score threshold and MQL volume rises overnight, with no change in buyer behavior.
    • Run broader top-of-funnel webinars and every registrant inches over the line.
    • Buy a syndication list and import thousands of “leads” who never chose to hear from you.

    None of this requires anyone to lie. It only requires a team under quarterly pressure to quietly redefine success, which is exactly what input metrics invite.

    There is a deeper problem: MQLs count individuals, but B2B purchases are made by groups. Forrester’s 2023 Buyers’ Journey Survey found that 93% of B2B buyers participated in a buying group of two or more people, and 71% in a group of four or more. A thousand MQLs can contain zero complete buying groups.

    What changes when you report on pipeline

    Pipeline is harder to fake. A demand gen team that reports on qualified pipeline created per quarter has to care about what sales accepts, what converts, and what closes. That is the core of the argument, and it holds before you touch a single benchmark.

    The second-order effect is on channel strategy. When channels are ranked by opportunities created rather than form fills, the portfolio changes: syndication and incentivized content downloads usually fall, while high-intent search, referrals, and durable organic presence usually rise. Gartner’s research on the B2B buying journey describes buying as a nonlinear loop across six jobs, from problem identification through consensus creation, with much of it happening away from your sales team. If buyers do the bulk of that work independently, the channels that meet them there are the ones that create pipeline. That is one reason we treat organic growth automation as pipeline infrastructure rather than a branding exercise.

    How to make the transition

    The switch is mostly definitional and political, not technical. A workable sequence:

    • Run a cohort analysis first. Take the last four quarters of MQLs and trace each cohort through to opportunity conversion and pipeline generated, by channel. This gives you a baseline and, in most teams, makes the case for you. The gap between MQL volume and pipeline contribution by channel is rarely flattering.
    • Agree the definition in writing. Qualified pipeline should mean an opportunity sales has accepted, at an agreed stage, valued by a consistent rule. If marketing gets to value its own pipeline, you have rebuilt the MQL problem one stage later.
    • Report both metrics in parallel for a quarter or two. Leadership needs to see the new number behave before the old one disappears.
    • Move targets and compensation last. Change what is reported before you change what is paid on.
    • Fix CRM hygiene early. Opportunity source fields and stage timestamps carry the whole system. If they are unreliable, the new metric will be too.

    Objections and honest trade-offs

    This is not a free upgrade, and the objections are mostly legitimate.

    Pipeline is a lagging indicator. With a six-to-nine month sales cycle, this quarter’s work shows up in next year’s number. Keep leading indicators, such as qualified meetings and high-intent engagement, as internal instrumentation. Report outputs; steer with inputs.

    Marketing does not control sales acceptance. True, and partly the point: a metric both teams touch forces the alignment conversation that MQLs let everyone avoid. It does require a service-level agreement on follow-up, or marketing gets punished for sales capacity problems.

    Pipeline can be gamed too. Inflated deal values and junk opportunities exist. Pipeline is harder to fake than MQLs, not impossible. Guard it with shared stage definitions and regular win-rate reviews.

    Attribution gets murkier. Tying pipeline back to channels involves judgment calls that no model resolves cleanly. Use models to inform allocation, not to settle credit disputes; attribution models are maps, not territory.

    One honest hedge: if you sell a low-priced product on a two-week cycle, or you are a two-person team that needs volume signal just to learn, MQL-style metrics can still earn their keep. The argument here is for teams whose MQL number has drifted away from revenue, which in our experience is most teams past a certain size.

    Report the number that has to survive contact with sales and finance. It will be smaller, slower, and more argued over. It will also be real.

    About the author: Shivaa Tripathi leads digital and performance marketing at Exotel and writes about demand gen, AI search, and the systems behind them at shivaatripathi.com. He built organic-os, the open-source AI SEO agent this site documents. LinkedIn · GitHub

    Drafted with organic-os and human-reviewed before publishing — every change on this site is approved by a person and logged publicly on the live proof page. Published 2026-07-18 · Updated 2026-07-21.

  • A Practical Intro to Answer Engine Optimization for B2B SaaS

    Answer engine optimization is the practice of making your content a source that AI assistants such as ChatGPT, Perplexity, and Google’s AI Overviews cite when they answer your buyers’ questions. For B2B SaaS, the work comes down to three things: letting AI crawlers reach your site, structuring pages so individual sections can be quoted verbatim as answers, and being unambiguous about what your product is and who it serves. It extends SEO rather than replacing it, and most of the underlying work overlaps. The evidence base is young, so treat what follows as a defensible starting point, not settled practice.

    How AI assistants answer buyer questions differently from search results

    A search results page gives your buyer ten links and lets them choose. An assistant gives them one synthesized answer with a handful of citations, and most of the time they never click through. That changes what you are competing for: not a ranking for a keyword, but selection as the source an assistant pulls a specific passage from.

    Google’s documentation describes AI Overviews and AI Mode using a “query fan-out” technique, issuing multiple related searches behind the scenes and assembling the answer from a diverse set of supporting pages. In practice, a page that would never rank first for a head term can still get cited if one of its sections answers a sub-question cleanly.

    Keep the volumes in perspective. In Ahrefs’ study of 3,000 websites, 63% received at least one AI-referred visitor, but AI referrals averaged about 0.17% of traffic, with ChatGPT, Perplexity, and Gemini sending 98% of it. The authors note the real numbers are probably higher because some assistants strip referrer data, but this is still a small channel today. The case for working on it now is that the buyers who arrive this way tend to be deep into evaluation.

    What actually influences citations

    Three things show up consistently across platform documentation and independent testing.

    Structure and extractability. Assistants quote passages, not pages. A section with a descriptive heading, a direct answer in the first sentence or two, and evidence immediately after is easy to lift. A 400-word paragraph that buries its point is not. The test I use: could this section be quoted verbatim as an answer and still make sense?

    Entity clarity. Assistants need to know what your product is, what category it sits in, and who it is for. If your site describes the product five different ways across five pages, you make that harder. One plain-language definition, used consistently, helps retrieval and attribution alike.

    Basic technical eligibility, not special markup. Google says appearing in its AI features requires nothing beyond normal indexing and snippet eligibility, and explicitly advises against creating special AI files or schema for the purpose. Independent data points the same way: when Ahrefs tracked 1,885 pages that added JSON-LD schema, AI citations barely moved on any platform, even though cited pages were about three times more likely to carry schema in the first place. That looks like correlation with overall site quality, not cause. I dig into this in whether schema markup helps AI citations.

    A practical starter checklist for a B2B SaaS site

    • Confirm AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot are not blocked by robots.txt, your CDN, or your firewall. Check server logs, not just config files.
    • Rewrite your top ten organic pages so every H2 section opens with a direct answer to the question its heading implies.
    • Make each section self-contained: claim, evidence, source. Assume it will be read out of context, because it will be.
    • Write one canonical definition of your product and category, and use it on the homepage, about page, and key product pages.
    • Cover the comparison and alternatives questions buyers actually ask assistants, honestly, including where you are not the right fit.
    • Keep normal SEO hygiene. A page that is not indexed and snippet-eligible is not a citation candidate at all.

    How to measure whether it works

    Referral traffic. Track sessions from assistant domains like chatgpt.com and perplexity.ai in GA4, monthly. I walk through the setup in how to track AI referral traffic in GA4. Note that Google folds AI Overviews traffic into the ordinary Web search type in Search Console, so you cannot fully isolate it there.

    Citation checks. Keep a list of 20 to 30 real buyer questions, ask them in the major assistants each month, and log whether you are cited. Crude, but it measures the actual thing you are optimizing.

    Conversion quality. Segment AI-referred visitors and watch what they do. Ahrefs reported that 0.5% of its visitors from AI search drove 12.1% of signups in a 30-day window. That is one company’s funnel, and the authors themselves caution against generalizing, but it fits the intuition that assistant-referred visitors arrive pre-qualified.

    The honest limits of the evidence

    Most published AEO evidence is correlational, single-company, or vendor-produced. Platforms change their retrieval systems without notice, so what correlates with citations this quarter may not next quarter. Referrer stripping means traffic data undercounts by an unknown amount. And nobody, including the platforms, can tell you how to guarantee a citation.

    I still think the work is worth doing, because nearly everything on the checklist is also just good content practice. Clear structure, direct answers, consistent product definitions, and honest comparison pages help human readers and conventional rankings whether or not an assistant ever cites you. That makes AEO a low-regret bet, which, given the state of the evidence, is the right kind to make.

    About the author: Shivaa Tripathi leads digital and performance marketing at Exotel and writes about demand gen, AI search, and the systems behind them at shivaatripathi.com. He built organic-os, the open-source AI SEO agent this site documents. LinkedIn · GitHub

    Drafted with organic-os and human-reviewed before publishing — every change on this site is approved by a person and logged publicly on the live proof page. Published 2026-07-15 · Updated 2026-07-21.

  • How to Structure a B2B SaaS Keyword Portfolio

    Structure a B2B SaaS keyword portfolio the way a portfolio manager structures positions: group keywords into three intent buckets (category, problem, and comparison terms), weight each bucket by expected return (volume x intent x winnability), and rebalance on a fixed schedule. Review rankings monthly and the portfolio itself quarterly. Cut any position that has not moved in two quarters and reallocate the effort to the buckets that are paying.

    Group keywords by intent: the three position types

    Every keyword sits somewhere on the path from “I have a problem” to “I am choosing a vendor.” Ahrefs’ guide to search intent splits queries into informational, navigational, commercial, and transactional, and notes that many queries mix intents, so treat any classification as a starting point rather than a law. For B2B SaaS, three working buckets cover most of the ground:

    • Category terms describe the software category itself, like “call center software.” They carry buying intent, but everyone knows it, so they are the most expensive positions on the board.
    • Problem terms describe the pain before the buyer knows the category exists, like “agents keep missing inbound calls.” Finding them requires actually talking to customers, which is why most teams skip them.
    • Comparison terms include competitor names and alternatives queries. They convert best of all, because the searcher has already decided to buy and is choosing between shortlisted vendors.

    Most teams overinvest in category terms because they are obvious, and underinvest in problem terms because they are not. The fix is mechanical: for every category page, commission two problem-led essays that link to it.

    Weight positions by expected return

    A flat list treats every keyword as equally important, which means nothing is. A portfolio assigns each position a weight, and the weight is a product of three factors:

    • Volume: how many people search for it. Necessary, but the least interesting factor. Problem terms often show near-zero reported volume and still source real pipeline.
    • Intent: how close the searcher is to money. A hundred visits from an alternatives query are worth more than ten thousand from a definitional one.
    • Winnability: whether you can realistically reach the top of the page. Semrush defines keyword difficulty as a 0-100 measure of how hard it is to earn a top position, and Ahrefs adds the caveat that the score is derived largely from backlinks to the current top-ranking pages, so read it against your own site’s authority, not in a vacuum.

    Multiply the three and the ranking of your buckets usually inverts. Comparison terms, small in volume, come out heavily overweight. Category terms, big and difficult, get a smaller allocation than instinct suggests. That is what weighting means: effort follows expected return, not search volume.

    Rebalance on a schedule: the monthly review

    Rankings get reviewed monthly; the portfolio itself gets reviewed quarterly. Keep the two separate, because they answer different questions.

    The monthly review is a read, not a rewrite. Pull rankings, organic traffic, and signups or demos per bucket. Note what moved, flag what has been flat, and check whether new competitors entered the results for your comparison terms. Resist the urge to edit pages every month: positions need time to mature, and constant tinkering makes it impossible to tell what worked. The pull itself is mechanical, which makes it exactly the kind of work an AI SEO agent can run on schedule while you keep the judgment calls.

    The quarterly review is the rebalance. This is where you reallocate: commission new problem essays for category pages that lack them, add comparison pages for competitors that started showing up in your deals, and decide which flat positions go on the kill list.

    When to cut a position

    The rule is deliberately blunt: a page that has not moved in two quarters gets cut, and the effort gets reallocated. Sunk cost is the portfolio’s enemy. A page you spent forty hours on is not an argument for keeping it.

    Cutting does not always mean deleting. Diagnose first:

    • Consolidate when two of your own pages compete for the same query and split the ranking signal between them. That is keyword cannibalization, and one merged page usually outperforms both of the pages it replaced.
    • Reposition when the page is sound but aimed at the wrong query. Rewrite it against a different keyword and restart its two-quarter clock.
    • Retire when the page exists only to hold a keyword. Google’s helpful content guidance is explicit that its ranking systems reward content made to benefit people, not pages manufactured to occupy a search result. Delete it, redirect it, move on.

    Why this beats a flat keyword list

    A flat keyword list only grows. Nobody deletes rows from a spreadsheet, so it accumulates every keyword anyone ever suggested, all implicitly equal, none with an owner or a review date. Effort gets allocated to whatever was added most recently or argued for most loudly.

    A portfolio forces three questions a list never asks:

    • What intent does this keyword serve, and which bucket does it belong to?
    • What return do we expect, and what else could the same effort buy?
    • When will we admit it failed?

    Portfolio managers get fired for holding losers out of attachment. Hold your keyword sheet to the same standard: grouped by intent, weighted by expected return, reviewed on a schedule, and pruned without sentiment.

    About the author: Shivaa Tripathi leads digital and performance marketing at Exotel and writes about demand gen, AI search, and the systems behind them at shivaatripathi.com. He built organic-os, the open-source AI SEO agent this site documents. LinkedIn · GitHub

    Drafted with organic-os and human-reviewed before publishing — every change on this site is approved by a person and logged publicly on the live proof page. Published 2026-07-12 · Updated 2026-07-12.

  • Attribution Models Are Maps, Not Territory

    No attribution model tells you what caused a deal. Each one is a map: a simplified, deliberately distorted picture of a messy buying journey. So the useful question is never which model is right, because none of them are. The practical move is to run two or three, act where they agree, investigate where they disagree, and check any large budget decision against stronger evidence, such as an incrementality test or direct customer feedback.

    Every common model is biased in a known way

    Attribution models do not measure credit. They assign it, according to a rule somebody chose. Each rule distorts in a predictable direction:

    • First touch gives all credit to the earliest recorded touchpoint. It overvalues top-of-funnel content and any channel that harvests cheap first clicks.
    • Last touch gives all credit to the final touchpoint. It overvalues brand search, direct, and whatever sits closest to the demo form, and it erases the work that created the demand in the first place.
    • Linear splits credit evenly across every touch. That sounds fair, but it is really a refusal to decide: strong signals get diluted and weak ones get inflated.
    • Position-based models hard-code the assumption that the first and last touches matter most, typically weighted 40/20/40. The weighting is arbitrary, not observed.
    • Data-driven attribution uses machine learning across converting and non-converting paths, which is genuinely better. But it can only redistribute credit among touchpoints your tracking can see, so it inherits every blind spot in your setup.

    Why “which model is right” is the wrong question

    A subway map and a topographic map of the same city disagree almost everywhere, and both are useful. Neither is the city. Attribution models work the same way: each answers a narrow question about observed digital clicks, and none of them observes the territory where B2B deals actually form – a colleague’s recommendation, a podcast mention, a Slack community thread, a conversation at a conference.

    The territory has a habit of embarrassing the map. When eBay paused its brand keyword ads in a large-scale field experiment, researchers found the ads had no measurable short-term benefit: buyers who would have clicked the ad simply arrived through organic search instead. Click-based reports had made that same spend look like some of the company’s best-performing. If your last-touch report says brand search is your top channel, you may be looking at the model’s bias, not the channel’s contribution.

    Use models as directional instruments

    A compass does not tell you where you are, but it keeps you walking in a consistent direction. Use attribution the same way:

    • Triangulate. Run at least two models side by side. Where they agree a channel is working, trust the signal more. Where they diverge, investigate – divergence usually flags early-funnel activity that last-click erases.
    • Ask humans. A free-text “How did you hear about us?” field on every form routinely surfaces channels no model can see. Read the raw answers, not just the categorized rollup.
    • Test incrementality where it counts. For your one or two largest budget lines, run a holdout: pause the channel in one region or segment and watch what actually changes. It is the only method here that measures cause rather than assigning credit.
    • Anchor everything to revenue. A model arbitrating credit for form fills optimizes the wrong thing entirely; this is the same logic behind reporting on pipeline instead of MQLs.

    What changed with GA4 and privacy

    Google has quietly conceded much of this argument. As of November 2023, GA4 removed the first click, linear, time decay, and position-based models entirely, leaving data-driven attribution and last-click variants. The models most obviously disconnected from buying reality are simply gone from the product.

    Privacy changes pull in the same direction. When visitors decline cookies, GA4’s behavioral modeling for consent mode uses machine learning to estimate their behavior from similar users who accepted. Portions of your reports are now modeled rather than observed – a reasonable response to consent requirements, and one more reason to treat the numbers as estimates, not ground truth. Meanwhile, new territory keeps appearing faster than the maps update: AI assistants now send real referral traffic that default channel groupings handle poorly, which is worth tracking deliberately in GA4.

    Practical guidance for a B2B team

    You do not need a data science team to do this well. You need discipline about what the numbers can and cannot say:

    • Pick one primary model and write its known bias directly on the dashboard, so nobody forgets what they are reading.
    • Review data-driven against last click quarterly. Reallocate budget only where they agree, and treat disagreement as a research prompt, not an error to reconcile.
    • Keep a self-reported attribution field on every form and read it monthly alongside the model output.
    • Before scaling or cutting a major channel, run a simple holdout test rather than arguing about credit weights.
    • Match your lookback window to your sales cycle. A 30-day window on a six-month cycle guarantees the map is missing most of the journey.

    A model that is wrong in a known way is still useful. A model mistaken for reality is how budgets get misallocated. Keep the map. Just stop billing the territory for it.

    About the author: Shivaa Tripathi leads digital and performance marketing at Exotel and writes about demand gen, AI search, and the systems behind them at shivaatripathi.com. He built organic-os, the open-source AI SEO agent this site documents. LinkedIn · GitHub

    Drafted with organic-os and human-reviewed before publishing — every change on this site is approved by a person and logged publicly on the live proof page. Published 2026-07-09 · Updated 2026-07-09.

  • The Case for Fewer, Deeper Case Studies

    Most B2B SaaS teams should publish fewer case studies and make each one much deeper. A wide-and-shallow library – twenty logos, three paragraphs each, a pull quote – gets skimmed and forgotten, while one 2,000-word story with real numbers, named failure points, and decision context earns trust that no logo wall can. Buyers now run most of their evaluation without talking to sales, so the case study has to do the work a reference call used to do. One deep case study per segment, shipped one per quarter, is the better trade.

    Why wide-and-shallow case study libraries underperform

    The standard case study is a template: a challenge, a solution, a percentage improvement with no baseline, and a quote from a VP who clearly did not write it. Twenty of these side by side do not read as twenty proofs. They read as one ad, repeated. A buyer skims one, learns nothing they could not have guessed from the homepage, and leaves.

    Skepticism is the default state of a B2B evaluator. Gartner’s sales survey found that 69% of B2B buyers report inconsistencies between what a vendor’s website says and what its sellers tell them. Generic customer stories feed that doubt instead of resolving it. A claim like 40% faster onboarding with no starting point, team size, or timeline is unverifiable, and buyers treat unverifiable claims as marketing. There is a search cost too: twenty near-identical pages compete with each other for the same handful of queries, and none is substantial enough to rank or be cited for anything specific.

    What a deep case study actually contains

    Depth is not length for its own sake. It is the presence of details a reader could check, or recognize from their own environment:

    • Real numbers with denominators. Ticket backlog fell from 1,400 to 300 in nine weeks is believable. A bare 78% reduction is not.
    • Decision context. Why the customer bought, what else they evaluated, who inside the account objected and why.
    • Failure points. The integration that broke, the migration that ran long, the workaround that fixed it. Naming what went wrong is the strongest credibility signal available to a vendor.
    • Named specifics. The stack, the team size, the rollout sequence, the time to first value.
    • Operator voices. Quotes from the admin who ran the rollout, not only the executive who approved it.

    A story with these elements reads like a colleague’s account instead of a brochure. That is the entire point.

    How buyers actually use case studies

    Modern B2B evaluation happens mostly out of the vendor’s sight. The same Gartner survey found 61% of B2B buyers prefer a rep-free buying experience. TrustRadius’s 2024 B2B Buying Disconnect research found that 71% of buyers went with the product that was already their first choice when they built a shortlist, which means your content does its persuading before anyone fills out a form. The same research found 56% of buyers talked to an existing user before purchasing. A deep case study is the scalable version of that conversation: it answers what a reference call answers – what actually broke, how long it really took, what the team looked like.

    Case studies are also internal sales tools. Your champion forwards them to the CFO and the security reviewer to argue your case when you are not in the room. Marketers already know the format works: in the Content Marketing Institute’s 2025 B2B benchmarks, case studies and customer stories ranked among the top content types for producing results, and three quarters of B2B marketers used them. The format is not the problem. The execution is.

    Depth earns citations, including from AI assistants

    Specifics are quotable; generalities are not. A writer covering onboarding benchmarks can cite a backlog that fell from 1,400 tickets to 300 in nine weeks. Nobody links to significant improvement. The same logic now applies to AI assistants: when a buyer asks ChatGPT or Perplexity whether a product fits a mid-market team migrating off a legacy system, the engines favor pages with concrete, extractable facts – numbers, named integrations, described scenarios. Shallow case studies give them nothing to extract. Deep ones map directly onto the long-tail questions buyers actually ask, which is the core mechanic in our practical intro to answer engine optimization for B2B SaaS.

    A practical production model: fewer per quarter, more access

    The constraint on deep case studies is not writing capacity. It is access. So restructure the ask:

    • One per quarter, one per segment. Map your two or three core segments and aim for one definitive story in each, refreshed as the numbers change.
    • Trade volume for access. Instead of asking ten customers for a quote, ask one for ninety minutes with the admin who ran the rollout, a look at the real dashboard, and sign-off on specific numbers.
    • Interview the skeptic. The person who argued against the purchase gives you objection-handling material no template produces.
    • Retire the shallow ones. As each deep study ships, redirect the thin pages in that segment to it. Twenty weak pages dilute; one strong page compounds.
    • Systematize the pipeline. Interview scheduling, transcript processing, approval tracking, and refresh reminders are exactly the repeatable work an automated content operations setup should carry, so human effort goes into the interviews and the storytelling.

    The trade is fewer logos on the wall in exchange for stories buyers finish, sales sends unprompted, and machines cite. Make it.

    About the author: Shivaa Tripathi leads digital and performance marketing at Exotel and writes about demand gen, AI search, and the systems behind them at shivaatripathi.com. He built organic-os, the open-source AI SEO agent this site documents. LinkedIn · GitHub

    Drafted with organic-os and human-reviewed before publishing — every change on this site is approved by a person and logged publicly on the live proof page. Published 2026-07-06 · Updated 2026-07-06.