Azure AI Search (2026-05-01-preview): ASPX page content field returns raw JSON/canvas data instead of extracted text

Mathias Stenlund 10 Reputation points
2026-08-06T13:05:00.7133333+00:00

Service: Azure AI Search, SharePoint in Microsoft 365 indexer, API version 2026-05-01-preview

Context: I'm using the new allSitePages container type (introduced in 2026-05-01-preview) to index modern ASPX site pages from a SharePoint Online site. Per the documentation (Index content from SharePoint in Microsoft 365), page text should be "extracted into the content field." My indexer and skillset map /document/content as input to a SplitSkill for chunking followed by an AzureOpenAIEmbeddingSkill. Which is the same pipeline I use successfully for regular document library files.

Issue: The indexer runs and pages are indexed (confirmed via content_type: "SitePage") but the content field doesn't contain clean extracted page text. Instead it contains what looks like the raw HTML-entity-escaped JSON of the page's canvas data, including internal properties like controlType, pageSettingsSlice, GUIDs. In other words, not readable or useful page text which is obviously problematic when running the embedding skill.

Here is a truncated snippet of the content field for an indexed document.

      "content_type": "SitePage",
      "content": "{\"odata.type\":\"SP.Data.SitePagesItem\",\"odata.id\":\"12345\",\"odata.etag\":\"\\u0022110\\u0022\",\"odata.editLink\":\"Web/Lists(guid\\12345...

This happens to every ASPX-page I've indexed and observed so far. For contrast, the documentation states that for SharePoint list items (a different container type, allSiteLists), content is expected to contain JSON-formatted field values, but for pages, the documented expectation is extracted text, not JSON. What I'm seeing for pages resembles the list-item behavior rather than the documented page behavior.

Environment:

  1. API version: 2026-05-01-preview
  2. Data source container: { "name": "allSitePages" }
  3. Key field mapping: metadata_spo_site_asset_item_id to id (base64Encode)
  4. Authentication: Federated credential (system-assigned managed identity), Graph permissions Files.Read.All + Sites.Read.All, SharePoint API permission Sites.Read.All

Troubleshooting:

  1. Confirmed via content_type in the index that these are correctly identified as SitePage items so the extraction path is seemingly routing correctly by content type.

To reproduce:

  1. POST a data source with container.name: "allSitePages" pointing at a site with modern ASPX pages.
  2. Create an indexer targeting this data source with dataToExtract: "contentAndMetadata" and the key field mapped from metadata_spo_site_asset_item_id.
  3. Create index and run indexer.
  4. Inspect the content field (or whatever derived from /document/content) on an indexed page document.

Is this a known limitation of this preview of the 2026-05-01-preview when extracting from modern ASPX-pages or is there a configuration step that I'm missing to make this work in this version of the preview?

Azure AI Search
Azure AI Search

An Azure search service with built-in artificial intelligence capabilities that enrich information to help identify and explore relevant content at scale.

0 comments No comments

2 answers

Sort by: Newest
  1. Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator
    2026-08-06T20:22:15.0633333+00:00

    Hi @Mathias Stenlund

    Thanks for reaching out in Microsoft Q&A forum,

    Your configuration appears to be aligned with the documented requirements for the SharePoint in Microsoft 365 indexer using the allSitePages container. The issue does not appear to be related to authentication, key field mapping, indexer configuration, or the skillset pipeline.

    The behavior you are seeing does not match the documented behavior for allSitePages. According to the documentation, when indexing modern SharePoint pages, the page text should be extracted into the content field. In contrast, JSON-formatted field values are expected for SharePoint list items (allSiteLists).

    In your case, the documents are correctly identified as content_type: "SitePage", but the content field contains the underlying SharePoint page item JSON (SP.Data.SitePagesItem) with properties such as controlType, pageSettingsSlice, and GUID values instead of readable page text. This suggests that the page classification is working correctly, but the content extraction stage is not producing the expected text output.

    There does not appear to be any additional configuration setting, field mapping, or skillset change that can enable the text extraction behavior. The extraction process is handled internally by the SharePoint connector.

    As additional validation, you can consider checking the following:

    • Test with a simple modern SharePoint page containing only a text web part to confirm whether the behavior occurs across all page layouts or only specific page types.
    • Verify whether metadata fields such as metadata_spo_item_name, metadata_spo_item_weburi, and metadata_spo_item_last_modified are populated for the affected page documents.
    • Review the indexer execution history for any warnings related to content extraction, even though the indexer run completes successfully.

    If you need to continue building the RAG pipeline while this behavior is being investigated, a possible workaround is to preprocess the SharePoint page content and extract the readable text before passing it to SplitSkill and AzureOpenAIEmbeddingSkill. Another option is to use the SharePoint retrieval approach recommended for RAG scenarios, which retrieves textual content directly from SharePoint.

    Based on the current information, this appears to be a mismatch between the expected allSitePages extraction behavior documented for the preview API and the content returned by the indexer, rather than a configuration issue on your side.

    For reference, please see the official documentation:

    Kindly let us know if the above helps or you need further assistance on this issue.

    Please do not forget to 210246-screenshot-2021-12-10-121802.pngand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

    Was this answer helpful?

    2 people found this answer helpful.

  2. Nithin 330 Reputation points
    2026-08-06T14:58:09.7166667+00:00

    Hi Mathias,

    This behavior happens because the allSitePages container in the 2026-05-01-preview indexer reads the raw SharePoint modern page canvas data (CanvasContent1 JSON), rather than running it through an HTML text extraction step first.

    Since modern ASPX pages store web parts as JSON strings inside SharePoint, the indexer ingests the raw layout payload unless you transform it in a skillset.

    Here is how to extract clean text:

    1. Add a Document Extraction Skill or HTML Strip Skill to your Azure AI Search skillset: Use the #Microsoft.Skills.Util.DocumentExtractionSkill or a custom Web API skillset step to parse the raw canvas JSON into plain text before mapping to the content field.
    2. Map Output Field: Ensure your indexer's outputFieldMappings maps the extracted text skill output (/document/extracted_text) to your target index content field, rather than mapping directly from /document/CanvasContent1.

    This separates the raw SharePoint page JSON from the clean text used for vector search / RAG retrieval.

    Ref: Azure AI Search Skillset Concepts

    If this helps resolve the indexing issue, please mark as Accept Answer!

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.