llms.txt отображается кракозябрами: исправляем UTF-8 в Nginx

Коротко: что делать

Проверьте `curl -I https://example.com/llms.txt`: если нет `charset=utf-8`, убедитесь, что содержимое действительно UTF-8. Для физического файла добавьте `charset utf-8;` в точный `location = /llms.txt` Nginx или обратитесь в поддержку. В LLMS.txt Editor 1.2.0 доступна проверяемая альтернатива через WordPress, но только при поддержке `.txt`-маршрутизации сервером.

Если русский текст в /llms.txt виден в браузере как набор символов наподобие Р…, сначала проверьте кодировку содержимого, а затем HTTP-заголовок ответа. Частый случай: текст уже записан в UTF-8 правильно, но Nginx отдаёт его как text/plain без charset=utf-8. Тогда браузер может интерпретировать байты в другой кодировке.

Шаг 1. Посмотрите ответ сервера

curl -I https://example.com/llms.txt

Обратите внимание на две строки:

HTTP/2 200
Content-Type: text/plain

Если charset не указан, причина искажения может быть в определении кодировки браузером. Сам по себе этот заголовок ещё не доказывает, что файл повреждён.

Шаг 2. Проверьте байты файла как UTF-8

curl -sS https://example.com/llms.txt | python3 -c 'import sys; print(sys.stdin.buffer.read().decode("utf-8")[:500])'

Русский текст читается нормально — не перекодируйте файл, переходите к настройке HTTP-заголовка.
Возникает UnicodeDecodeError — содержимое не является корректным UTF-8; проверьте исходный файл, способ сохранения и преобразуйте текст в UTF-8 без потери данных.
В консоли тоже выводятся искажённые символы — вероятно, они уже сохранены в файле: найдите корректную резервную копию или восстановите текст в редакторе.

Шаг 3. Исправьте Nginx

Если управляете Nginx, можно добавить точное правило для /llms.txt в нужный server {}. Пример требует адаптации под конфигурацию хостинга:

location = /llms.txt {
    types { }
    default_type text/plain;
    charset utf-8;
    try_files $uri =404;
    expires 1h;
}

Здесь charset utf-8; задаёт кодировку ответа; types { } и default_type text/plain; задают тип для данного location. Перед изменениями сделайте резервную копию конфигурации, проверьте nginx -t и перезагрузите сервер в порядке, принятом у вашего хостинга. Документация Nginx по charset.

На виртуальном хостинге доступ к server {} может отсутствовать. Тогда передайте технической поддержке запрос: для /llms.txt вернуть Content-Type: text/plain; charset=utf-8. При необходимости попросите сократить время кеширования или очистить кэш CDN.

А если нет доступа к конфигурации Nginx?

LLMS.txt Editor версии 1.2.0 умеет проверить заголовок из админки WordPress и, после отдельного подтверждения администратора, попробовать выдавать /llms.txt средствами WordPress. Перед включением плагин проверяет прохождение .txt-запросов к WordPress, а после переключения проверяет реальный ответ и при неуспехе пытается вернуть физический файл.

Этот способ не универсален: если Nginx не передаёт отсутствующие .txt-адреса в WordPress, нужно исправлять конфигурацию сервера. Виртуальная выдача также зависит от работы WordPress и активного плагина.

Шаг 4. Убедитесь, что исправление сработало

curl -I 'https://example.com/llms.txt?check=1'

Проверьте 200 и ожидаемый Content-Type: text/plain; charset=utf-8. Если браузер продолжает показывать старый вариант, очистите серверный/CDN-кэш и повторите проверку в новой вкладке. Параметр check=1 не всегда обходит принудительное кеширование у всех посредников.

Чего не нужно делать

Не добавляйте BOM только ради исправления заголовка.
Не преобразовывайте исправный UTF-8 в Windows-1251.
Не редактируйте .htaccess с ожиданием, что это повлияет на статический ответ Nginx: он не использует правила Apache.
Не удаляйте физический llms.txt вручную ради виртуального режима без резервной копии и проверки маршрутизации.

Источник: https://nginx.org/en/docs/http/ngx_http_charset_module.html

Материал был полезен?

Помогите нам сделать материалы точнее и понятнее.