Table of Contents
A public website knowledge source lets a Microsoft Copilot Studio agent ground answers in pages that Bing can index within a URL scope you define. It is appropriate for public documentation, product information, policies, and help content that does not require sign-in.
It is not a web scraper and does not bypass authentication. Content must be publicly reachable, indexed by Bing, and within Copilot Studio’s supported URL structure. For private SharePoint or enterprise content, use the corresponding authenticated knowledge source instead.
Add a public website knowledge source
- Open the agent in Copilot Studio.
- On Overview or Knowledge, select Add knowledge. You can also configure knowledge in a generative answers node when the design requires topic-specific grounding.
- Select Public websites.
- Enter the public URL. To use a variable, select the variable control beside the field and choose an eligible custom, system, or environment variable.
- Give the source a clear name.
- Write a specific description of what the site contains and when the agent should use it. Descriptions help generative orchestration select among sources.
- Select Add to agent.
- Test the agent with questions that the site should answer, questions near the edge of its scope, and questions it should refuse or route elsewhere.
Microsoft’s current instructions are maintained in Add a public website as a knowledge source.
How public website grounding works
Copilot Studio uses Bing search to find relevant indexed pages within the configured website scope. The agent does not automatically ingest every page into a private database. This has several practical effects:
- A publicly accessible page may still be unavailable if Bing has not indexed it.
- A newly published or changed page may not appear immediately.
- Robots directives, canonical URLs, redirects, or weak internal linking can affect discovery.
- Authenticated wikis, portals, and SharePoint sites are not valid public website sources simply because their URLs are known.
The broader Copilot Studio knowledge-source documentation distinguishes public web sources from authenticated SharePoint, Dataverse, documents, and connector-backed enterprise data.
URL depth and scope rules
A configured public URL can contain no more than two path levels after the domain. A trailing slash does not add another level.
| Example | Result |
|---|---|
https://www.contoso.com | Valid domain-level source |
https://www.fabrikam.com/engines/rotary | Valid two-level path |
https://www.fabrikam.com/engines/rotary/ | Valid; trailing slash is allowed |
https://www.fabrikam.com/engines/rotary/dual-shaft | Invalid because it exceeds the supported path depth |
The path sets the search scope. A source configured as https://www.fabrikam.com/engines/rotary can use indexed pages beneath that path, such as /engines/rotary/dual-shaft, but it does not use a sibling path such as /tools.
Domain and subdomain behavior
Be deliberate about the hostname:
https://www.fabrikam.comscopes to thewwwhost and does not automatically includenews.fabrikam.com.https://fabrikam.comcan cover indexed content under the registered domain, including subdomains, according to the public-website source rules.- If a configured URL redirects to a different top-level site, pages on the destination site are not automatically added to the original source’s scope.
Test the final canonical URL rather than assuming that a marketing redirect will work.
URLs to avoid
- Search-engine result pages: adding
bing.comor another search engine does not create a useful source boundary. - Sign-in pages: the public website source cannot access protected content.
- Private SharePoint or wiki URLs: configure the authenticated knowledge-source type instead.
- Broad forums or social feeds: user-generated content can be irrelevant, offensive, inaccurate, or difficult to moderate. Limit the scope or choose reviewed documentation.
- Deep content URLs: move the configured root up to a supported path and test whether retrieval remains precise enough.
Use a variable in the knowledge URL
A variable can replace the complete URL or a path segment. Copilot Studio resolves it at runtime, which lets one knowledge source change scope according to product, language, environment, or another controlled input.
https://www.contoso.com/{Global.Path}
or:
{Global.KnowledgeURL}
The resolved value must still be a valid supported URL. A variable changes the target; it does not bypass depth limits, authentication rules, or Bing indexing.
Create and set the variable
- Create a String variable with Global scope.
- Set its value from a controlled source such as a topic input, user-language property, environment variable, agent flow, or connector.
- In the knowledge-source URL field, select {x} Insert variable and insert the global variable.
- Test every allowed value and an invalid or unexpected value.
Do not place arbitrary user text directly into a URL. Map user choices to an allowlist of approved domains or paths so a prompt cannot redirect grounding to an untrusted site.
Example: route by product
Suppose an agent supports Copilot, Teams, and Surface. Capture the product in Topic.Product, then define a table of approved paths:
Table(
{ Product: "Copilot", Path: "microsoft-365-copilot" },
{ Product: "Teams", Path: "microsoft-teams" },
{ Product: "Surface", Path: "surface" }
)
Store that table in Topic.ProductTable. Set a global string variable from the approved match:
LookUp(
Topic.ProductTable,
Product = Topic.Product,
Path
)
Then configure the source:
https://www.microsoft.com/en-us/{GlobalProductURL}
Add a fallback for unmatched values. If the lookup returns blank, the agent should ask the user to choose a supported product rather than constructing an incomplete URL.
Other useful variable patterns
| Scenario | Safe implementation |
|---|---|
| Language or region | Map a user-language value to approved locale segments such as en-us or it-it |
| Development, test, production | Use environment variables containing approved base URLs |
| Product documentation | Map a product selection to a known path instead of accepting a free-form URL |
| Customer-specific public help | Validate the tenant or customer key against an allowlist before resolving the domain |
Test retrieval before publishing
A successful “Add” action only confirms that the source configuration is accepted. It does not prove that the agent will retrieve the right page for every query. Build a test set containing:
- Direct questions with one clear answer on the site.
- Questions whose answer appears on a deeper page within scope.
- Questions about a sibling path that should not be used.
- Recently changed information.
- Ambiguous questions that could match multiple products.
- Questions with no answer in the source.
- Prompts attempting to override the agent or inject an unapproved URL.
Check citations and the exact page used. A fluent answer without the correct supporting page is not a successful grounding result.
Troubleshooting
| Problem | Check |
|---|---|
| No result from a known page | Confirm the page is public, indexed by Bing, canonicalized correctly, and inside the configured path |
| Irrelevant pages appear | Narrow the root URL and improve the source description |
| Redirected site is ignored | Configure the final supported domain directly |
| Variable source returns nothing | Inspect the resolved string, scheme, hostname, path depth, and blank-value handling |
| Private content is missing | Use an authenticated SharePoint, Dataverse, document, or enterprise connector source |
| Agent answers from general knowledge | Review the agent’s generative settings and whether ungrounded responses are allowed |
Use the narrowest public URL that covers the intended material, write a descriptive source summary, constrain variable values, and evaluate citations with realistic questions. Those steps matter more than simply adding a large number of websites.
Reader Comments 0
Sign in with email or Google to join the discussion.