Why ChatGPT uses your job postings to describe your tech stack

You type your company's name into ChatGPT and ask how your product is built. The output tells you that your backend runs on Python, uses PostgreSQL for transactional storage, relies on Redis for caching, and streams events through Kafka.

Your public marketing site mentions none of these choices. Your homepage speaks in vague enterprise terms about cloud scalability and high availability architecture. Yet the language model lists your exact infrastructure tools with detailed accuracy.

The model did not breach your internal documentation. It read your public job postings.

Career pages as technical documentation

When engineering managers write job descriptions, they need qualified candidates. To filter out unqualified applicants, they write precise technical requirements. A senior backend job post might specify Python 3.11, FastAPI, PostgreSQL, Redis, Kafka, AWS ECS, and Datadog.

These job descriptions live on public domains. They sit on third-party applicant tracking systems like Lever, Greenhouse, and Workable, and they are mirrored directly on your careers page.

To a large language model, a marketing page is a low-signal text source. Marketing copy contains broad adjectives and corporate abstract concepts. A job posting, by contrast, contains dense, structured facts. It pairs a specific brand name with specific software tools, databases, cloud vendors, and security protocols.

When training pipelines collect web data or when real-time answer engines search the web to evaluate your architecture, career listings offer the clearest snapshot of what your engineering team actually uses.

How training crawlers and answer crawlers ingest job listings

Understanding how job postings reach an AI answer requires separating two distinct mechanisms: model training and web retrieval. Conflating these two mechanisms leads companies to block the wrong web crawlers.

Model training occurs months or years before a prompt is run. Training crawlers sweep job boards, corporate sites, and tech blogs to build massive static datasets. If your job posts were indexed during a training run, that information becomes baked into the parameters of the model.

Real-time retrieval occurs when a user submits a prompt to an engine that has live web search enabled. When you ask an engine a question today, an answer crawler might run a live search query across job boards to see what your company currently hires for.

The crawlers that perform these tasks are entirely separate entities.

In our crawler index, published on 2026-08-08, we analyzed a panel of 54,082 domains. Of those, 33,670 domains returned a readable robots.txt file. Within those readable domains, 5,497 block at least one AI agent, but only 2,576 block at least one answer crawler.

The breakdown across training crawlers shows significant block counts among readable domains:

• GPTBot (training): 5,080 out of 33,670 domains block it.
• ClaudeBot (training): 4,603 out of 33,670 domains block it.
• Google-Extended (training): 4,275 out of 33,670 domains block it.

The breakdown for search and answer crawlers shows different numbers:

• PerplexityBot (search): 2,147 out of 33,670 domains block it.
• ChatGPT-User (search): 2,074 out of 33,670 domains block it.
• OAI-SearchBot (search): 1,579 out of 33,670 domains block it.
• Perplexity-User (search): 1,402 out of 33,670 domains block it.
• Claude-SearchBot (search): 1,400 out of 33,670 domains block it.
• Claude-User (search): 1,384 out of 33,670 domains block it.

In our Y Combinator census run on 2026-08-07, out of 4,226 active companies, 3,755 had readable robots.txt files, and 253 blocked at least one AI crawler.

If you block GPTBot in your robots.txt today, you stop OpenAI from using your job pages in future base model training sets. You do not stop ChatGPT-User or OAI-SearchBot from reading your Greenhouse job listings in real time to answer a user's prompt about your tech stack right now.

Why historical job postings create lasting hallucinations

Product architectures change over time. Teams migrate from AWS to GCP, or swap MySQL for Snowflake.

However, job postings from three years ago often linger on third-party job aggregators or older web snapshots. If GPTBot ingested dozens of job postings from 2022 hiring for MySQL expertise, ChatGPT will continue to state that your product runs on MySQL.

This creates a stubborn discrepancy between current reality and AI output. Changing the text on your active careers page does not remove historical training data from a model that has already been trained.

Furthermore, vendors who attempt to solve this issue by adding schema markup or creating an llms.txt file are wasting effort. Schema markup tells search engine indexers how to parse structured data, but it does not overwrite parameter memory inside an LLM. We have no evidence that schema markup or llms.txt improves or changes AI citations, and relying on them diverts focus from actual source data.

Measuring how engines report your technology stack

Because LLMs are non-deterministic, running a single prompt about your architecture provides an incomplete picture. Asking ChatGPT once whether you use AWS or Azure might yield AWS. Asking it again in a fresh session might yield both, or neither.

Single-run checks are misleading. Many monitoring tools run a prompt once, observe a result, and present it as a firm factual score. A single output run is not a valid measurement.

At Standing, our method uses a fixed prompt basket across five engines: ChatGPT, Perplexity, Gemini, Claude, and Google AI Overviews. We run each prompt five times per question per engine and apply a Wilson interval to the result.

If ChatGPT cites a legacy database from your old job posts in 4 out of 5 runs, the score is expressed with its confidence band, such as 80 out of 100, plus or minus 18, within a 95% confidence interval. This accounts for output variance and prevents false conclusions based on random generation drift.

Competitor platforms like Profound or enterprise AI suites offer broader enterprise integrations and custom executive dashboards. Where those tools are genuinely better is in high-level reporting for executive suites that require custom security permissions. However, they execute each prompt only once, which hides output variance and leaves you without a confidence interval.

If you are tracking your brand footprint across AI engines, Standing offers three straightforward tiers:

• Track: $100 per month for 3 domains.
• Optimize: $300 per month for 5 domains with custom prompts.
• Agency: $500 per month for 50 domains with a monthly re-scan.

How to audit and manage your job posting exposure

Controlling what AI engines report about your tech stack requires sustained coordination across departments. You cannot instantly edit historical model parameters, but you can manage live retrieval and future training ingestion.

First, conduct a systematic prompt audit across target engines. Run specific queries:

• What software stack does [Company] use in production?
• What primary database powers [Company]?
• What third-party vendor APIs does [Company] rely on?

Cross-reference the engine outputs against current and legacy job listings on Greenhouse, Lever, and third-party aggregators. You will frequently find verbatim matches from job descriptions written years ago.

Second, adjust job description templates going forward. Engineering leads should describe necessary experience without listing sensitive architectural details or non-essential vendor names. Writing "experience with modern distributed messaging queues" instead of naming specific secondary vendors prevents engines from binding those vendors to your core product profile.

Third, configure your robots.txt file based on actual crawler functions. If you want to prevent answer engines from fetching live job listings during search retrieval, block answer crawlers such as ChatGPT-User, OAI-SearchBot, and Perplexity-User. If you want to restrict future training datasets, block GPTBot, ClaudeBot, and Google-Extended.

Do not buy services promising guaranteed removal of historical facts from model weights. No vendor can edit trained weights inside a compiled model. Controlling career page messaging takes deliberate effort across marketing and engineering, and updating engine outputs requires time as base models retrain.