11 сентября 2026 года Cloudflare обновил AI Search: сервис теперь умеет индексировать объекты в R2 без расширения файла, если у объекта задан поддерживаемый Content-Type. Раньше безопаснее было рассчитывать на распознаваемое расширение в object key. Теперь хранилища с ключами вроде UUID, hash или внутренних идентификаторов могут передавать тип документа через метаданные.
Изменение небольшое по формулировке, но практичное для AI-поиска по корпоративным документам, базам знаний и файловым архивам. Оно убирает необходимость переименовывать объекты только ради индексатора, но делает качество MIME-метаданных обязательной частью пайплайна.
Что именно изменил Cloudflare
В официальном changelog Cloudflare указано, что AI Search может индексировать R2-объекты без filename extension, если они содержат поддерживаемый Content-Type. При этом проверка типа файла сохраняется: отсутствие расширения не означает, что индексатор будет принимать произвольные байты.
В документации R2 data source Cloudflare уточняет порядок определения типа: распознаваемое расширение остаётся предпочтительным и более быстрым путём. Для extensionless-объектов требуется явный MIME-тип.
Почему это важно для реальных R2-хранилищ
Object key в R2 не обязан быть обычным именем файла. В API-интеграциях часто встречаются ключи вроде docs/7f8d2a..., UUID, хэши контента или внутренние идентификаторы. Такой подход удобен для дедупликации и стабильных ссылок, но по самому ключу нельзя понять, лежит внутри PDF, Markdown, JSON или изображение.
После обновления AI Search может опираться на метаданные объекта. Например, объект без суффикса .pdf может быть распознан как PDF при корректном Content-Type: application/pdf.
Какие Content-Type поддерживаются
Поддержка зависит от таблицы типов данных AI Search. В документации Cloudflare перечислены, среди прочего, text/plain, text/markdown, application/json, application/pdf, text/html, application/xml, text/csv, а также несколько MIME-типов изображений и офисных документов.
Cloudflare отдельно предупреждает: extensionless-объекты с отсутствующим, неподдерживаемым, некорректным Content-Type или универсальным application/octet-stream не поддерживаются AI Search. Поэтому «файл скачивается из браузера» ещё не означает «файл готов к индексации».
Что проверить в существующем bucket
- У объектов без расширений действительно задан
Content-Type, а не только пользовательские metadata. - MIME соответствует фактическому формату содержимого.
- Вместо
application/octet-streamиспользуется поддерживаемый конкретный тип. - Размер файла укладывается в лимиты AI Search.
- Include/exclude path filters не исключают нужные object keys.
- После изменения metadata выполнена новая синхронизация data source и проверены indexing errors.
Почему нельзя просто выставить всем application/pdf
Метаданные должны описывать реальные байты. Если JSON пометить как PDF, проблема лишь переносится дальше по цепочке: парсер получает неверное ожидание формата и индексация может завершиться ошибкой. Правильнее формировать MIME в момент загрузки объекта и считать его частью контракта между приложением и R2.
Для старых архивов полезно отдельно пройтись по объектам без расширений, определить тип по исходной системе или фактическому содержимому и обновить metadata контролируемо. Массово менять тип «по умолчанию» без проверки — плохая стратегия.
Как это влияет на AI Search и RAG
AI Search подключает источник данных, преобразует поддерживаемые документы, разбивает текст на части и строит индекс для поиска. Поэтому качество ingestion начинается раньше embeddings и модели генерации. Если документ не распознан как поддерживаемый файл, до этапа поиска он просто не дойдёт.
Для RAG-сценария это означает простую вещь: до настройки промпта и модели нужно проверить слой данных. Корректные object key, MIME, доступ, path filters и статус синхронизации часто важнее попыток «улучшить ответ» только настройками LLM.
Что не изменилось
Cloudflare не отменил ограничения типов и размера файлов. В актуальной документации AI Search максимальный размер отдельного файла — до 4 MB. Неподдерживаемые форматы и файлы сверх лимита пропускаются и фиксируются как ошибки индексирования.
Не изменился и общий принцип R2 data source: внешнее хранилище синхронизируется с AI Search, а сам объект остаётся в bucket. Новое поведение лишь расширяет способ определения формата для ключей без расширения.
Где это особенно полезно
- корпоративные базы знаний, где ключи генерируются приложением;
- архивы документов с UUID вместо исходных filenames;
- пайплайны импорта из CRM, helpdesk или внутренних API;
- системы, где стабильный object key важнее человекочитаемого имени;
- AI-агенты, которые ищут по документам из R2 через AI Search.
Как A.S Groups может помочь
Если AI Search подключается к уже работающему R2 bucket, полезно сначала проверить не только настройки поиска, но и сам ingestion-пайплайн: как создаются object keys, кто выставляет Content-Type, какие файлы попадают под фильтры и где фиксируются ошибки синхронизации.
A.S Groups занимается AI-автоматизацией, API-интеграциями и веб-инфраструктурой. Если R2 или Cloudflare используются рядом с WordPress, можно также заказать доработку WordPress. Описать задачу можно через контакты.
Частые вопросы
Нужно ли теперь удалять расширения у файлов в R2?
Нет. Cloudflare по-прежнему считает распознаваемое расширение предпочтительным способом определения типа. Новая поддержка нужна тем объектам, у которых расширения уже нет по архитектуре хранилища.
Подойдёт ли application/octet-stream?
Нет. В документации Cloudflare этот универсальный MIME прямо указан как неподдерживаемый для extensionless R2 objects в AI Search.
Можно ли индексировать PDF без .pdf в object key?
Да, если объект действительно является PDF и у него задан поддерживаемый Content-Type: application/pdf.
Нужно ли переименовывать существующие object keys?
Не обязательно. Если ключи стабильны и без расширений, можно сохранить их и привести в порядок Content-Type metadata.
Что проверить, если объект всё равно не индексируется?
Проверьте MIME, размер файла, path filters, доступность объекта для подключённого источника и журнал ошибок индексирования.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.