In short. Perplexity follows a fetch_url redirect when possible, while the returned url field remains the requested address.
Definition: No. Perplexity documents that
fetch_urlfollows an HTTP redirect when it can fetch the destination, while theurlfield in the returnedfetch_url_resultsitem remains the URL requested by the caller. The field therefore identifies the requested URL rather than the final redirect destination.
Key facts
- Perplexity describes
fetch_urlas a tool that fetches and extracts content from a URL during an Agent API request. Its documented use case is a page, article, document or report that the application already knows. Perplexity's fetch URL documentation says the tool is for “specific URLs”. - The documented result can contain a
fetch_url_resultsitem before the final assistant message. Each fetched content item includes a URL, a page title and an extracted snippet. - The redirect behavior is explicit: HTTP redirects are followed when the destination can be fetched, but the returned
urlreflects the requested URL. - RFC 9110 defines the HTTP
Locationvalue as the URI reference that a server supplies for a redirect. That protocol meaning does not change Perplexity's documented result-field meaning.
What does the returned record identify?
Perplexity's response shape puts fetched items under fetch_url_results.contents. The example contains url, title and snippet fields:
{
"type": "fetch_url_results",
"contents": [
{
"url": "https://example.com/report",
"title": "Example Report",
"snippet": "Extracted content from the fetched page."
}
]
}
The documentation assigns a specific meaning to url for redirects. If the supplied address returns a redirect and the destination can be fetched, the fetch proceeds, but the result item's url keeps the supplied address. The response shape shows no separate final_url, redirect chain or Location field.
That distinction matters when an application stores fetch records. A record's url can be used to match the result to the request that triggered it. It cannot, from this field alone, identify the last address reached after following redirects.
What does HTTP say about redirects?
RFC 9110's HTTP Semantics describes a redirect as a response whose target can be under another URI. For a 301 response, the target has a new permanent URI and the server should send a Location field containing a preferred URI reference. A user agent may use that value for automatic redirection.
The status code changes the meaning of the redirect. A 302 response places the target temporarily under another URI. A 303 response lets a user agent retrieve the URI in Location, and that retrieval can itself be redirected. A 307 response requires the user agent to keep the request method when it performs an automatic redirect. These protocol rules describe the exchange between client and server; they do not require a higher-level API to replace its requested-URL field with the final URI.
How should a result be checked?
Keep the URL supplied to fetch_url beside the returned item. Use the returned url as the request identifier, then inspect the HTTP exchange separately when the final destination matters. RFC 9110 identifies the redirect target through the Location response field, while Perplexity documents the result field as the requested URL.
Perplexity does not document a separate final-destination field for fetch_url results. A consumer that needs that value should retain the redirect response data from its own HTTP check rather than infer it from fetch_url_results.contents[].url.
Related terms
- How can a Perplexity Agent read a known webpage directly?
- How are inaccessible pages marked in Perplexity fetch results?
- HTTP redirects
- How do I request extracted page content from Perplexity search?
FAQ
Does fetch_url follow HTTP redirects?
Yes, when the destination can be fetched. The result still records the URL supplied to the tool.
Does the returned url become the final destination?
No. Perplexity's documented behavior keeps the requested URL in that field.
Can the result record reveal a redirect chain?
No redirect chain field is documented in the response shape. Check the HTTP exchange separately if the sequence of destinations matters.
Sources
Check how a page reads to answer engines. Open the GEO score analyzer