AI answers most engineering questions without looking anything up
Most advice about AI visibility assumes the AI goes and looks something up. Publish the right page, the thinking goes, and the engine will find it and cite it.
For engineering questions, that's often not what happens.
Search is optional, and often skipped
AI assistants decide for themselves whether to search. In our pilot, we gave Claude its web-search tool, let it decide whether to search as the consumer product does, and asked 52 engineering questions worded the way engineers ask them. Claude searched on 18 of the 52. The other 34 answers came entirely from what the model learned during training.
Whether it searched depended on the kind of question:
How often Claude searched the web, by question intent
Questions where Claude, asked plainly, ran at least one web search
Table view
| Count | Of | Share | |
|---|---|---|---|
| Supplier discovery | 5 | 5 | 100% |
| Compliance | 1 | 1 | 100% |
| Material selection | 10 | 24 | 42% |
| Comparison | 2 | 10 | 20% |
| Process selection | 0 | 7 | 0% |
| Troubleshooting | 0 | 5 | 0% |
It searched for every supplier-discovery question ("Which companies supply…") and the one compliance question. It searched for fewer than half of the material-selection questions, two of ten comparisons, and none of the troubleshooting or process questions. Questions such as "How do I reduce compression set in an injection-molded EVA midsole?" or "What causes melt fracture in extruded LLDPE?" were answered from memory, in detail, with no sources at all.
Add "Please cite your sources." and the behavior flips: Claude searched for all 52, about three searches per answer. Engineers who want references can get them. Most questions, though, are asked plainly.
Why it matters
If a question is answered from training data, nothing you publish this week changes the answer. What counts is what was public, readable and widely referenced when the model was trained. That has three practical consequences.
Durable, public technical content is an asset with a long half-life. The processing guides, troubleshooting notes and comparison pages a supplier publishes now are what future models will know about its materials. Content behind forms, inside script-rendered product finders or only in PDFs nobody links to is far less likely to be learned.
Decide deliberately about training crawlers. Training crawlers (such as GPTBot and ClaudeBot) feed future models; search crawlers and user-triggered fetchers put pages into today's answers. In our audit of 77 materials and manufacturing websites, almost no supplier blocked AI agents in robots.txt. Several of the big datasheet databases and trade publications, though, block the training crawlers outright. If that trend continues, suppliers' own pages become the likeliest place future models learn grade-level facts. That's an argument for keeping them open and making them good.
Retrieval still decides the rest. Supplier-discovery and compliance questions did trigger search, and there the page an engine can find and quote today wins. Both levers matter; they just apply to different questions.
What to do
- Publish the troubleshooting and processing knowledge your technical service team already has, as public HTML pages with test conditions stated.
- Keep the facts engineers need in front of any form wall.
- Treat training-crawler access as a strategic decision, not a default.
- Measure how often engines search for your questions at all. If they don't, retrieval tactics won't move the answer.
This pilot used one run per question; the search rate will vary between runs and model versions. The paper sets out the method and limitations.
Method, data and limitations: What AI Tells Engineers →