Many sites keep their best content in PDFs: case studies, whitepapers, datasheets, and brochures. Visitors search for a phrase from one of those documents and find nothing because search only knows about the content that has been sent to it. The text inside a PDF is not sent by default.

This guide explains how to fix that without code. It covers the approach, the components involved, how to configure a push source and its fields in SitecoreAI, and what to watch out for.

Which product is this? This guide covers Search experiences in SitecoreAI, not the older standalone Sitecore Search product (the Customer Engagement Console). Their setup and APIs differ, so make sure the documentation you follow refers to "Search experiences" and "SitecoreAI".

The Idea in One Minute

A search experience searches a source that you control. A source is a collection of documents, and each document contains fields such as a title, description, and body of text.

To make PDFs searchable, you:

1. Create a push source, an empty source that holds only what you send to it.
2. Define the fields each PDF will have, including its title, body text, and link.
3. Run a small sync tool that reads your PDFs, extracts the text from each one, and sends it to the push source.
4. Point your search experience at that source.

The sync tool is the only custom component. Everything else is configured in SitecoreAI.

Architecture

Reading the architecture from left to right:

• Media Library: Holds the PDFs. When they are published, Experience Edge can list them and provide their public links.
• Sync tool: Runs outside Sitecore. It lists the PDFs, downloads each one, extracts the text (using OCR if the PDF is a scan), and builds one document per PDF.
• Push source: Receives those documents through Sitecore's Ingestion Service API.
• Search experience: Searches the source and displays the PDFs in your site's search results, with a link to each file.

Why a Push Source?

SitecoreAI offers different types of sources. A site source holds pages that Sitecore crawls, while a content source holds content that comes from Sitecore itself. A push source holds only what an external system sends to it.

A push source is well suited for PDFs for two reasons:

• Control over indexed content: You choose the title, text, and link for each PDF.
• Protection from re-indexing: Sitecore warns that when a site or content source is re-indexed, anything pushed to it through the API can be lost. A push source treats your synchronization process as the source of truth, avoiding that risk.

Before You Start

You will need:

• Published PDFs in the Media Library: Only published items are visible to Experience Edge, so unpublished PDFs are skipped automatically.
• Access to Search experiences: Sitecore describes the feature as rolling out in phases, so it may not be visible in every organization yet.
• Permission to create an API key: In production, only Organization Owners and Organization Admins can create API keys.
• Experience Edge access: An endpoint and API key so the tool can list the PDFs.
• A place to run the sync tool: Such as a developer machine, scheduled job, or build pipeline.

Step 1: Create the Push Source

Create a new source in SitecoreAI's search sources and choose the push source type. Sitecore's documentation covers this under "Manage push sources".

1. Give the source a clear name, such as "PDF Documents".
2. Choose the locale or locales your documents use, for example, English.
3. Save the source. You will add its fields next.

Step 2: Add the Fields (Attributes)

Each PDF becomes one document made up of fields. This step matters because the API does not create fields automatically. If the sync tool sends a field that does not exist in the source, the document is rejected. Field names are also case-sensitive, so "Title" and "title" are different fields.

Add one field for each piece of information you want to search, display, or filter on:

A few considerations when choosing fields:

• Keep the field set small: Only add fields you will use. You can always add more later.
• Be careful with the body: An API request can be at most 512 KiB, so very long PDFs should be trimmed. Searching the first part of a long document is usually sufficient.
• Use the required date format: If you include updated_at, the API only accepts dates written as YYYYMMDDTHHMMSSZ (for example, 20250115T093000Z). Standard formats like 2025-01-15T09:30:00Z are rejected.
• Avoid reserved field names: Sitecore ignores fields whose names begin with sc_, so do not use that prefix.
• Keep field names consistent: The names above are suggestions. What matters is that the sync tool uses exactly the names you create.

Step 3: Publish the Source

A source must be published before it can receive documents. If you try to push to an unpublished source, the API responds that the configuration was not found. After publishing, the source is ready, although it is still empty.

Step 4: Collect the Connection Details and Create an API Key

The sync tool needs to know where to send documents and must have permission to do so. Collect the following details:

To create the key, open the source's settings, choose "Create credential", give it a name, and copy the key. The key is shown only once, so store it securely immediately, such as in a password manager or your pipeline's secret store.

Treat the API key like a password. Never put it in a repository or screenshot.

Sitecore's documentation describes the exact menu path in two slightly different ways, so confirm it in your own instance.

Step 5: Build the Sync Tool

The sync tool is the one component you create yourself. Each time it runs, it performs the following steps:

1. Lists the PDFs: It asks Experience Edge for every published PDF in the Media Library, along with each item's title, description, last-updated date, and public link.
2. Downloads each PDF: It fetches the file into memory. This is required for full-text search because Experience Edge provides the file's details but not its contents.
3. Extracts the text: Most PDFs contain text that can be read directly. Scanned PDFs contain images of pages, so the tool uses OCR (optical character recognition) to extract the words. OCR is slower, so limiting the number of pages it processes is recommended.
4. Cleans the text: It joins words split across lines, removes extra spaces, and trims content that is too long.
5. Builds one document per PDF: It populates the fields from Step 2, including the title (the editor's title or the file name if empty), description (the editor's description or the beginning of the extracted text), body, link, and other fields.
6. Sends the documents: It sends them to the push source's API Endpoint in small batches, using the API key. Each request can contain at most 50 documents and 512 KiB, so larger sets must be split into smaller batches.

You can write this tool in any language. It can run on a schedule, manually, or after a publish event.

What the Tool Sends

Every document is sent as an upsert. The first time a PDF's ID is sent, it is added. Sending the same ID again updates that document.

Each document needs a unique ID, and the Media Library item's ID works well. Using the same ID every time prevents duplicates.

The tool should also handle problems gracefully:

• If the server reports that some documents succeeded and others failed, only the failed documents need to be sent again.
• If the server is temporarily unavailable, wait and retry.
• If a request is rejected because of an error such as an incorrect field name or invalid API key, stop and report it. Retrying will not resolve the issue.
• One corrupt PDF should not stop the entire run. Log the error and continue.

Important: The Ingestion Service API writes directly to the live index. There is no dry run or separate publish step. Test with a small number of PDFs first, and provide a "preview only" mode that shows what the tool would send without actually sending it.

Step 6: Show the PDFs in a Search Experience

Now connect the source to what visitors see:

1. Make sure the search experience uses the PDF push source.
2. Set the result title and link to the title and url fields.
3. Add doc_type as a filter if you want visitors to narrow results to PDFs.
4. Confirm that body is configured as searchable.

Then search for a phrase that appears only inside a PDF, not in its title. If the PDF appears in the results, the setup is working.

Keeping the Index Up to Date

PDFs change, so the sync process needs to run regularly. There are three approaches, and the right choice depends on how frequently your PDFs change.

Removed PDFs

Deletes require additional care. If you unpublish or delete a PDF in Sitecore and your tool only performs upserts, the old document remains in the index and can still appear in search results.

To remove it, the tool must send a delete request for that document's ID. To know what to delete, it needs to remember what it sent previously or react to an unpublish event.

Plan for this from the beginning because it is an easy step to overlook.

Common Problems

Summary

Indexing PDFs in SitecoreAI Search experiences comes down to four decisions:

1. Use a push source so you control what is indexed and re-indexing does not remove pushed documents.
2. Define fields that match exactly what your tool sends, including case sensitivity.
3. Build a small sync tool that lists the PDFs, extracts their text (with OCR for scanned documents), and upserts one document per PDF.
4. Decide up front how to keep the index current and remove PDFs that are no longer available.

Once these components are in place, visitors can find a PDF by searching for a phrase on any page inside it.

References

SitecoreAI Search experiences (the product covered in this guide)

• Ingestion Service API: The endpoint, document format, limits, and error codes.
• Search experiences: What a search experience is. Its navigation also covers sources, "Manage push sources", and search experience components.

Standalone Sitecore Search (related, but with a different setup and API)

• Using the Ingestion API to add content to an index
• Keep your indexes up to date with the Ingestion API and the API Push source
• Enhancing search with documents