GeoLook: a self-hosted pipeline for tracking whether AI engines mention your brand

The question GeoLook answers is whether AI engines name you at all

The README frames the problem in the plainest possible terms: users now ask ChatGPT, Perplexity, Gemini, DeepSeek or Doubao which tool is best for a task, or which of two products to pick. If your brand is not in the candidate set the model draws from, none of your other marketing work reaches that conversation. GeoLook is aimed at the people who need to know whether they are in that set and, if not, why. The repository describes the target as teams running GEO as a project rather than a campaign, including agencies that deliver GEO as a service and need a client-facing package. The README lists the packaging output explicitly: a diagnosis report, a strategy, an execution plan, a ticket CSV and an acceptance sheet. That list is a good indicator of who the tool is for. It is not a dashboard for watching traffic. It is a workflow that ends in a document a client or an internal owner can sign off on.

Sampling first, opinions second: the measurement model

The status stage samples real answers engine by engine and quantifies mention rate, rank and citation share. The README states that 17 engines are covered, split into 10 automated through APIs and 7 handled manually, with Google AI Overviews and Metaso named among the manual group. That split matters more than the headline number. Anything in the manual group is only as current as the last time a human ran the sample, and the README acknowledges this by recording sampling-environment provenance per sample: sandbox, incognito, dedicated profile, or personal, where a personal environment auto-downgrades to needs review. That is a sensible admission that a sample taken from a logged-in browser is not the same evidence as one taken from a clean profile. Each question in the bank also carries a diagnosis type, ordered in the README as suspected-negative, then competitor-dominated, then absent, then low-ranked. The ordering is the useful part: it tells you to look at a negative mention before you look at a missing one, because a wrong claim about your product is a different problem from silence. The sample library keeps raw answers browsable and correctable, and the README is explicit that regex parsing misreads happen through name collisions and negation, that corrections recompute metrics immediately, and that corrections survive re-sampling. That last property is what separates a sample library from a log file.

The four-layer audit chain and why Access gates everything

The site audit is organised as a dependency chain: Access, then Orientation, then Understanding, then Quotability. Each layer depends on the one above, and the README states that a failing Access layer makes everything downstream invisible to engines, with the fix order computed for you. This is the strongest design decision in the project. Most audit tools return a flat list of findings sorted by severity, which invites you to fix the easy item rather than the blocking one. A dependency chain forces the order. The Access layer is broader than a robots.txt read. The README describes RFC 9309-compliant robots parsing that catches wildcard-group blocks, shared user-agent groups and specificity overrides that line-by-line regexes miss. It also describes WAF and CDN differential probing with real AI-crawler user agents, on the grounds that robots may allow GPTBot while your CDN returns 403, a condition invisible from a browser. It checks X-Robots-Tag header noindex, validates llms.txt links, checks hreflang coverage, and looks for sitemap index pollution and duplicate title or content. The Quotability layer operates at passage level, on the premise that retrieval picks passages rather than pages, so a page with sections but no independently quotable passage gets flagged with a specific fix. The channel map covers 19 channels weighted by what the README calls real citation-corpus data, and the brand facts library is positioned as the single source of truth from which llms.txt, JSON-LD and content drafts are generated. Whether the citation weighting generalises to your category is something only your own sampling can tell you.

Tickets with acceptance criteria, and the 86% figure

The action stage turns findings into structured tickets carrying rationale, owner, effort, window and acceptance criteria. Each ticket also carries an independent risk grade, which the README separates from priority in a way worth quoting: priority says how important, risk says how careful. The three risk bands are low-risk quick wins, observe with 7-14-28-day recheck, and high-risk technical changes with backup and rollback discipline. Tickets show first-measured, current and target values in progress bars and reopen automatically on regression. The README states that 86% of tickets were auto-verifiable in the sample project, 18 of 21. Read that number carefully. It is a property of one sample project's ticket set, not a guarantee about yours, and the 3 remaining tickets required human judgement. The practical consequence is that a ticket whose acceptance criterion cannot be expressed as a measurable change will fall into that manual bucket and will need a person to close it. The content workbench alongside the tickets sorts a topic pool by not mentioned and no content, holds the required extraction blocks and brand facts, runs a citability pre-check, and includes a fabrication-risk lint for AI drafts. The deploy assets include llms.txt, JSON-LD and HTML snippets, plus an AI-traffic attribution pack with a GA4 channel-group regex, a server-log counting script and source-snapshot guidance. Publishing covers GitHub, WordPress drafts, WeChat OA drafts, a webhook, X and Reddit, with credential setup handled in a dialog.

Getting it running

The README badges state Python 3.9 or later, macOS or Linux, and three dependencies: requests, bs4 and lxml. The repository does not include an install transcript in the supplied material, so the exact bootstrap command is not something I can quote. What the material does establish is the shape of the setup. You need API credentials for the automated engines, and you need to decide which of the manual engines you will sample by hand, because those produce nothing until someone runs them. The README notes that the keyword mining stage uses Baidu suggest for China and Google autocomplete for global terms from brand, competitor and category roots, described as free public endpoints with no keys required. It also states that mining candidates are never added to the question bank automatically; adding is always a manual check, and each mining round is snapshot-diffed to flag rising demand, which the README says affects topic ordering but never metrics. Publishing integrations each carry a step-by-step credential guide inside the dialog, which suggests the credentials are entered in the UI rather than in a config file. The homepage is geolook.cc and a read-only live demo is linked from the README, which is the fastest way to see the dashboard before installing anything.

Where GeoLook is the wrong tool

The manual engine group is the clearest limitation. Seven engines are sampled by hand, and Google AI Overviews is one of them. If your visibility problem lives in AI Overviews, GeoLook can hold the samples and the diagnosis, but it cannot collect them for you on a schedule. The sampling-environment provenance field exists precisely because manual samples vary in quality, and a personal-environment sample is marked as needing review rather than trusted. A second limitation is geographic and linguistic. The keyword mining split is Baidu suggest for China and Google autocomplete for global demand, so if your market is a search engine outside those two, the mining stage gives you little. A third is that GeoLook is a measurement and planning layer, not a content system. It will tell you a page has no independently quotable passage and hand you the fix, but it will not rewrite the page. Teams without the capacity to execute tickets will accumulate a backlog. Finally, the README's own framing of the ticket pipeline assumes a project with an owner, an effort estimate and a window. If nobody in your organisation holds that role, the acceptance criteria have nobody to satisfy.

How it differs from the commercial GEO dashboards

The obvious alternative is a hosted GEO or AI-visibility tracker, the category that sells prompt monitoring as a subscription. The difference in approach is not the dashboard, it is where the evidence and the plan live. A hosted tracker typically samples prompts on its own infrastructure, shows you mention rates over time, and stops there. GeoLook runs on your machine, keeps the raw answers in a sample library you can correct by hand, and continues past measurement into a site audit with a dependency order, a ticket backlog with acceptance criteria, a content workbench and deploy assets. The trade is real in both directions. Self-hosting means you own the API keys, the sampling schedule and the manual work for the engines that have no API. A hosted service absorbs that labour and gives you a comparison set across customers, which a self-hosted install cannot. If what you want is a weekly number and a chart, a hosted tracker is less work. If what you want is a defensible record of what each engine said, on which date, from which environment, plus a plan tied to the pages that caused it, the self-hosted model is the one that produces that artefact.

Maintenance cost and licence

The project is MIT-licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That matters for agencies packaging GEO as a paid service, since the licence does not restrict selling the output. It is not legal advice and the licence text is the authority. On maintenance, the dependency list is short (requests, bs4, lxml), which limits the surface that breaks on a Python upgrade, but the real ongoing cost is elsewhere. Engine APIs change, and every automated engine in the 10-engine group is a dependency on someone else's endpoint and terms. The manual group costs human time on every sampling round. The keyword mining stage depends on Baidu suggest and Google autocomplete, both described as free public endpoints, which is a polite way of saying they are undocumented and can change without notice. The repository shows a v0.2.0 release dated 2026-08-08 with the summary four-layer checkup, sample library, sampling assistant, publishing loop, and the last push is dated 2026-08-10, so the project is active. The version number also tells you the honest thing: this is a 0.2 line, and the README describes features that a 0.2 release may still be settling.

Editorial conclusion

Adopt GeoLook if you already accept that AI visibility is measured per question and per engine, and you want the sampling, the site audit and the ticket backlog in one self-hosted place. Do not adopt it if you expect it to fix your visibility on its own: it produces samples, diagnoses and tickets, and the execution still happens on your site and in your publishing channels. Before committing, verify three things: that the engines you care about are reachable from your environment, that the manual engines you intend to use are actually sampled by hand, and that the four-layer audit chain reports your Access layer as passing, since a failing Access layer makes every downstream layer invisible to engines.

Official sources

1. aigclink/geolook on GitHub
2. License: MIT
3. Project website
4. README
5. Releases