Ошибка «headers already sent» в WordPress: причины и пошаговое исправление

Короткий ответ: Ошибка «Warning: Cannot modify header information — headers already sent» в WordPress возникает, когда до вызова функций wp_redirect(), wp_set_auth_cookie() или любой другой операции, устанавливающей HTTP-заголовки, в вывод уже попал какой-либо текст. Чаще всего виноваты лишние пробелы после закрывающего тега ?> в functions.php или другом php-файле.

Почему возникает ошибка headers already sent

Протокол HTTP устроен так: сначала сервер отправляет заголовки (headers) — тип контента, куки, код ответа, редирект. Затем — тело страницы (HTML). Как только началась отправка тела, заголовки менять нельзя.

WordPress вызывает session_start(), wp_redirect() или wp_set_auth_cookie() — все они модифицируют HTTP-заголовки. Если к этому моменту уже был выведен хотя бы один символ (пробел, перевод строки, невидимый Unicode-символ), PHP выбрасывает предупреждение «headers already sent».

Типичные причины

1. Пробелы после ?> в functions.php

Самая частая причина. Вы закрываете PHP-блок в functions.php тегом ?>, а после него — пустая строка или пробел:

add_action( 'init', 'my_custom_function' );
function my_custom_function() {
    // код
}
?>  ← вот здесь пробел или перевод строки

Даже один невидимый пробел после ?> — это уже «вывод», который блокирует заголовки.

Решение: просто удалите закрывающий тег ?>. В чистых PHP-файлах (без HTML) его не нужно ставить — PHP и так завершает выполнение в конце файла. Это рекомендуемая практика WordPress и PHP-FIG.

add_action( 'init', 'my_custom_function' );
function my_custom_function() {
    // код
}
// ?> — удалите эту строку

2. BOM-маркер (Byte Order Mark) в UTF-8

Когда вы сохраняете PHP-файл в некоторых редакторах (особенно Notepad на Windows), в начало файла может быть добавлен невидимый BOM-байт \xEF\xBB\xBF. Этот байт — первый символ вывода, который и вызывает ошибку.

Решение: Откройте файл в редакторе (VS Code, Sublime Text, PhpStorm) и пересохраните в UTF-8 без BOM. В VS Code это настройка "files.encoding": "utf8" и "files.autoGuessEncoding": true.

3. Пробелы в wp-config.php перед <?php

Файл wp-config.php обязательно должен начинаться с <?php — ничего до этого тега не допускается:

   ← даже пробел здесь вызывает ошибку
<?php
define( 'DB_NAME', 'database' );

Решение: Откройте wp-config.php, убедитесь, что первый символ в файле — это <.

4. Лишние символы в конце плагина или темы после ?>

Старые плагины и темы часто содержат закрывающий тег ?> в конце. После него может оказаться пробел, табуляция или перевод строки, случайно добавленный FTP-клиентом или редактором.

Решение: Проверьте все недавно установленные или обновлённые плагины. Найдите файлы, заканчивающиеся на ?>, и удалите этот тег.

5. Ошибки кодировки в файлах перевода (.mo/.po)

Иногда проблема не в PHP-файлах, а в некорректных файлах локализации. Если файл перевода повреждён, WordPress может вывести бинарные данные до отправки заголовков.

Решение: Обновите файлы перевода или временно переключите язык сайта на английский (США), чтобы проверить, исчезла ли ошибка.

Пошаговая диагностика

Шаг 1: Включите отладку

В wp-config.php добавьте:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DEBUG_LOG', true );

Теперь ошибка будет видна на экране и записана в /wp-content/debug.log.

Шаг 2: Определите файл и строку

Ошибка всегда указывает на файл и строку:

Warning: Cannot modify header information - headers already sent by
(output started at /var/www/wp-content/themes/your-theme/functions.php:15)

Это говорит: вывод начался в functions.php на строке 15. Откройте этот файл, посмотрите, что на строке 15 и на строках до неё.

Шаг 3: Проверьте пробелы в подозрительных файлах

• functions.php активной темы
• wp-config.php
• wp-settings.php
• Все недавно изменённые файлы

Используйте команду (через SSH или хостинг-панель), чтобы найти ?> с последующим пробелом/переводом строки:

grep -rl '?>$' /path/to/wp-content/themes/your-theme/*.php

Шаг 4: Проверьте дочернюю тему

Если у вас дочерняя тема, убедитесь, что functions.php дочерней темы не содержит закрывающий ?>. Многие начинающие разработчики копируют родительский шаблон и забывают убрать ?>.

Как исправить окончательно

Причина	Решение
?> в конце PHP-файла	Удалить ?>, оставить файл без закрывающего тега
BOM-маркер	Пересохранить в UTF-8 без BOM
Пробел перед <?php	Удалить всё до <?php
Плагин с ?>	Найти и удалить ?> в плагине (или обновить плагин)
Повреждённый .mo-файл	Переустановить языковой пакет

Профилактика

1. Никогда не ставьте ?> в чистых PHP-файлах. Только в шаблонах, где после PHP идёт HTML.
2. Настройте редактор на UTF-8 без BOM, отображение невидимых символов и trailing whitespace.
3. Добавьте в IDE правило: файлы .php должны заканчиваться переводом строки, но без ?>.
4. Используйте CI-проверки, если работаете в команде — добавьте линтер, который подсвечивает лишние закрывающие теги.

Когда обращаться к хостинг-поддержке

Если вы проверили все файлы, а ошибка остаётся — возможно, проблема на уровне PHP-конфигурации сервера (например, auto_prepend_file в php.ini выводит что-то до загрузки WordPress). Попросите хостинг-провайдера:

• Проверить auto_prepend_file и auto_append_file в php.ini
• Сбросить кеш OPcache
• Временно переключить версию PHP (7.4, 8.0, 8.1, 8.2)

Заключение

Ошибка «headers already sent» — одна из самых распространённых в WordPress, но и одна из самых простых в диагностике. В 90% случаев виноват закрывающий тег ?> в functions.php. Удалите его — и проблема исчезнет. Помните: в WordPress-разработке «не закрывать PHP-тег» — это не лень, а стандарт безопасности и хороший тон.

Автор: Александр, технический специалист WordPress. Дата публикации: 5 июня 2026. Последнее обновление: 5 июня 2026.