Research and Web Search with Claude: Cited Research and Verification

Version note: This post covers web search and Research in Claude as of 15 November 2026; plan rules, settings and limits were checked the same day in the Claude Help Center (support.claude.com). This post is based on the official documentation. Anthropic rolls new features out to accounts gradually, so some of what is described here may not show up in your account yet.

Guess First

Emre wants to map the risk of moving Bookstore.Api, part of Bookstore, the online bookstore used as the shared example across this site's series, from .NET 10 to .NET 11. He asked Claude, with Research, to "list the .NET 11 breaking changes that will affect Bookstore". A few minutes later a tidy twelve-item report came back, with a source link next to every item. The last sentence of the report says "This list covers all breaking changes in .NET 11." Selin's Google Drive was also connected in Emre's conversation, and the report contains a quote from the team's migration notes from last month.

Three questions: can you trust the report's "all breaking changes" claim? Which of the twelve links would you use without opening them? Did Claude ask Emre before reading the document in Drive during Research? The answer to the third question is in the Help Center's Research article; you will be able to answer the first two yourself by the end of this post.

Web Search: No Toggle, Claude Decides

In the unified experience there is no switch to turn web search on or off. The Help Center article "Enable and use web search" (https://support.claude.com/en/articles/10684626) and the article "Claude Cowork and chat are one Claude" say the same thing: Claude searches the web on its own when it thinks searching will help. In accounts still on the previous experience, you pick "Web search" from the "+" menu on the left of the message box and check it. On Team and Enterprise, an organization owner (Owner or Primary Owner) first has to turn the feature on under Organization settings > Capabilities.

According to the article, answers that use web search include direct citations to sources, links for further reading and, where appropriate, relevant quotes. If you put a URL in your message, Claude can also pull that page's content (web fetch). Image results come without a separate setting, each shown with a source link. On the usage side there are two notes: web search and web fetch count toward your usage limit, and having Claude read a long article through a link can use a large part of the limit, especially on the Free plan.

The practical consequence of having no toggle is this: if you want Claude to search, or not to search, you have to write it into the brief. A sentence like "answer only from the attached document, do not search the web" or "search the official documentation before you answer" does the job of the old switch. This is the most visible example of the "Claude picks its own tools" rule we discussed in the third post.

Research: When and How to Start It

Research works differently from a single search. According to the Help Center article "Use research on Claude" (https://support.claude.com/en/articles/11088861), Claude runs several searches that build on each other, chooses its next step based on what it finds and looks at different sides of the question. The feature is on the paid plans: Pro, Max, Ultra, Team and Enterprise; it works on the web, Desktop and the mobile app. In the unified experience you start it by typing /deep-research in the message box or by choosing "Research" from the "+" menu. In the previous experience, choosing Research shows a blue indicator below the message box, and Research needs web search to be on.

Two details in the article matter for models and limits. First, Research runs on Claude Opus 5.5 whatever model you selected in the conversation, falling back to Opus 4.8 when needed. On Team and Enterprise, if both models are turned off for a role, Research does not work for that role. Second, Research is subject to the same limits as a normal conversation but can use them up faster. In the second post we said "small setting for a small job"; Research sits at the other end of that rule, so keep it for questions that really need many sources.

When Research, when a normal conversation? If you are asking about a single fact ("what is the latest release of Entity Framework Core 10?"), the single search Claude runs when needed is enough. If you need to compare several sources, apply a list of changes to your own system or build a thorough table on a topic, Research pays off. The question that draws the line is this: does the answer sit on one page, or do you need to read several pages and combine them?

Research and Connectors: Combining Internal Documents with the Web

Research does not only search the web. According to the same article, it can also use Google Workspace (Gmail, Google Calendar and Google Docs) and any other connectors turned on in the conversation. Here is the answer to the third Guess First question: during Research, connector tools run automatically, without asking for approval on each use. Drive was on in Emre's conversation, so Claude read the migration notes without asking; that is the expected behavior.

This behavior has a consequence: before you start Research, look at which connectors and which tools are on in the conversation. The Help Center's custom connector article reminds you that connector tools can be called during Research without further approval and recommends turning off tools that can write and limiting request volume. Research with read tools on and write tools off is the simplest way to combine internal documents and the web safely. We will look at connectors and tool permissions in detail in the eighth post.

There are platform differences too. Research started on mobile searches only the web and skips connectors without showing any error; if you want internal documents searched as well, start Research from the web or Desktop. Tools from local MCP servers configured in Claude Desktop cannot be used in Research.

A Good Research Brief

A brief for Research is made of the same parts as the task brief in the third post, but two parts weigh more: the source rule and the output format. A good research brief says:

• Question: one sentence, in an answerable form; not "information about the migration" but "which changes affect us".
• Context: which parts of the system are in use; Claude can judge the impact only if it knows this.
• Scope and dates: which version, which date range; sources from the preview period stay out.
• Source rule: which domains count as primary, how secondary sources are marked, what to do when no source is found.
• Output format: a table that can be checked row by row, plus a list of areas that were not checked.

The last item is the one most often skipped. A plain-text report is easy to read but hard to verify; a table with one claim and one source per row can be split across the team and checked. Asking for "list the areas you did not check" also makes the report's scope visible: knowing where Claude did not look matters as much as knowing where it did.

Bookstore: Researching the .NET 11 Migration

.NET 11 became GA on 10 November 2026. Let's turn Emre's request into a brief that can be verified:

Research question: Which breaking changes in .NET 11 can affect Bookstore.Api
when we move it from .NET 10 to .NET 11?

About Bookstore.Api: ASP.NET Core Web API, EF Core with SQL Server,
BackgroundService workers, appsettings.json plus environment variables,
DateOnly fields in Order and Shipment, Linux containers.

Scope and sources:
- Only changes that ship in .NET 11 GA (November 2026), not previews.
- Primary sources: learn.microsoft.com and github.com/dotnet. Mark any other
  source as secondary and never use it as the only source for a claim.
- If you cannot find a primary source for something, say so instead of guessing.

Output:
1) A table: change, area, type of change, affects Bookstore.Api (yes/no/maybe),
   why, primary source URL.
2) A list of areas you did not check.
3) Say whether the official list itself claims to be complete.

The expected answer to this brief is a table where each row is tied to one change and one Microsoft Learn page, a short list of areas that were not checked, and one sentence about whether the official list is complete. You can see the answer to the third item on Microsoft's page yourself: the "Breaking changes in .NET 11" page (https://learn.microsoft.com/en-us/dotnet/core/compatibility/11, read on 15 November 2026, last updated 12 November 2026) describes itself as a work in progress and not a complete list, and leaves ASP.NET Core changes to a separate page. So the "covers all breaking changes" sentence in Guess First contradicts the primary source itself. That one sentence shows that Emre cannot use the report as it is.

Some items on the page look as if they touch the structure of Bookstore.Api we described: for example, under Extensions, IHost.RunAsync and IHost.StopAsync throwing when a BackgroundService fails, empty strings in chained configuration overriding earlier providers, and under Core .NET libraries a behavioral change around the TryParse methods of DateOnly and TimeOnly. The point to watch here is that the title alone is not enough. You know whether an item affects Bookstore when the item's detail page says what changes under which condition. Read the "affects" column in Claude's table as a list of places to look, not as a verdict.

After the first report, ask for the basis of specific rows in a second message:

For rows 3, 5 and 8 of your table, quote the exact sentence from the primary
source that supports the row, with its URL and the page's last update date.
If the page does not say it, change the row to "not confirmed".

This message forces Claude to tie its own claim to the source's own sentence; rows without a basis get marked "not confirmed". Then you do the checking. Asking the same five questions for each row makes it easier:

The same method works for bookstore-web's Angular version upgrades; there the primary source is the Update Guide on angular.dev (https://angular.dev/update-guide), the page that lists the steps once you pick the starting and target versions. If you put the checked table, with its date, into the technical documentation project from the fourth post, the team will not start from scratch at the next migration.

Reading a Citation

A citation is not evidence; it is the address of the evidence. The presence of a link does not show that the page behind it supports the claim; the model can tie a sentence to the wrong page, summarize an old version of a page or merge two sources into one sentence. The general mechanics of hallucination and the "cite, verify" habit are covered in the LLM Fundamentals series post "LLM Hallucination and Reliability: Cite, Verify, Measure"; the prompt side of asking for quotes in long documents is in the Prompt Engineering in Practice series post "Working with Long Documents and Context: Placement, Asking for Quotes, Chunking and Ordering for Prompt Caching".

As a Claude-specific practice, three habits are enough. Open the source of every claim that contains a number, a date or a version. Look at who wrote the source and when: a product's official documentation, release note or source code is primary; a blog post on the same topic, however good, is secondary. If a primary and a secondary source disagree, go with the primary one and note the disagreement; sometimes the secondary source describes an older state of the primary source, not its later update.

In Production

Web content can carry instructions. Research reads dozens of pages you did not pick; an instruction hidden in one of them can try to steer Claude into distorting the report or doing something with an open connector. Given that connector tools run without approval during Research, turning off write tools reduces this risk directly. The defensive side of the topic is in the LLM Application Security series post "Layered Defense Against Prompt Injection: Direct, Indirect and Multimodal Injection, Spotlighting and Privilege Separation".

Limits need planning. Research uses the limit faster than a normal conversation and always runs on an Opus-class model. Instead of everyone on the team researching the same question separately, running one research task and putting the checked result into a project shares both the limit and the checking effort.

The result is tied to a date. A research report describes the state on the day it was made, and sources such as Microsoft's page keep being updated. When you save the report, write down the date of the research and the day the sources were read; if the migration takes a few weeks, check the critical rows again right before the migration.

Common Pitfalls

Accepting a citation without reading it. The presence of a link does not show the claim is true. At least open the sources of rows that contain numbers, dates and versions.

Taking a secondary source for a primary one. A blog post or a forum answer is not the product's official documentation. Writing the primary domains into the brief and having secondary sources marked makes this mistake visible.

Assuming the report is complete. Claude saying "these are all the changes" means nothing if the source itself says it is not complete. Always ask for the list of areas that were not checked.

Starting Research with connectors on without thinking. During Research, tools run without asking for approval. Turn off write tools and turn on only the connectors you need.

Sending every question to Research. For a single fact, Research is both slow and expensive; the single search Claude runs in a normal conversation is usually enough.

A Small Experiment

★☆☆ In a normal conversation, ask for the latest version of a package you use; open the citation in the answer and compare the version number with the package's official page. Then ask the same question with "do not search the web, tell me only what you know"; note the difference between the two answers.

★★☆ Fill in the .NET 11 brief from this post with your own project's context and run it with Research. Pick three rows from the table and apply the five checks from the evaluation table. How many rows became "not confirmed", and how many "affects" reasons found a match in the code?

★★★ Write a research template for your team, with sections for question, context, scope, source rule and output format. Try it on two different topics (a version migration and a regulatory change) and decide which section needs changing every time.

We saw that Research can use connectors without approval. In the eighth post we move on to the connectors themselves: the Connectors Directory, tool permissions, adding your own MCP server as a custom connector and connecting Bookstore's MCP server to Claude with read tools only.