Как убрать лишний код из шапки WordPress без правки темы

Если вы поддерживаете сайт на WordPress и открываете исходный код страницы, где в head десятки строк непонятного назначения, эта статья для вас. Разберу, какой код WordPress кладёт в шапку по умолчанию, какие мета-теги и служебные ссылки стоит убрать и как сделать это без правки файлов темы.

Типичная ошибка выглядит так: владелец находит в исходнике тег generator с версией CMS, ищет «как убрать» и вставляет строку прямо в header.php. После обновления темы правка пропадает, а иногда ломает вёрстку. У WordPress для шапки есть штатный механизм, и чистка через него занимает несколько строк кода.

Сами лишние теги убираются функцией remove_action() с указанием хука wp_head, и делается это в functions.php дочерней темы или в собственном плагине. Мы в студии «Мельница» при запуске нового сайта делаем такую чистку первым делом, и она почти всегда короче, чем кажется новичку.

Статья про классическую тему WordPress, где шапка выводится через header.php. Для блочных тем принцип тот же, но файлы другие. Про Bitrix, OpenCart или конструкторы вроде Tilda здесь не пишу, там устроено иначе. Отдельно важно не задеть rel=canonical: он указывает поисковикам основную версию страницы.

Из шапки можно убрать многое, но удалять надо только то, что вы сами проверили в исходном коде страницы.

Наблюдение из практики студии «Мельница»

Что такое шапка сайта и какой код WordPress кладёт в head

Шапка сайта - это блок head в HTML-коде каждой страницы. Посетитель его не видит, но именно там лежат заголовок страницы, мета-описание, ссылки link rel=stylesheet на стили и скрипты, служебные мета-теги. WP не пишет этот блок вручную в каждом шаблоне. Он собирает head из фрагментов, которые добавляют тема, плагины и само ядро CMS.

Механизм называется хук wp_head. В файле header.php темы стоит вызов wp_head(), и в этом месте WordPress проходит по всем функциям, подключённым к хукам, и выводит их результат. Хук - это точка расширения: ядро и плагины через add_action() вешают свои функции на wp_head. Такую функцию называют callback-функцией, то есть той, которую вызывает хук. Она выполняется ровно там, где нужно, без правки разметки.

Для примера: ядро через wp_generator добавляет тег generator, и подключение лежит на том же хуке. Так же feed_links выводит ссылки на RSS основного сайта и комментариев, а print_emoji_detection_script подключает скрипт wp-emoji-release.min.js. Всё это попадает в head, хотя ни один из этих фрагментов не записан в файлах темы.

Почему шапку правят через хуки, а не вручную в файле? Правка header.php привязана к теме: при смене темы или её обновлении строка пропадает или ломает сайт. Если плагин кэша или SEO уже добавил свой вывод в wp_head, ручная правка шаблона его не отменит. Хуки работают поверх любой темы и с плагинами обычно не конфликтуют.

Почему не стоит править functions.php темы напрямую? Потому что при обновлении родительской темы правки в её functions.php стираются. Код лучше положить в functions.php дочерней темы или в собственный плагин. Выглядит это так, на PHP:

function my_head_code() {
 echo '<meta name="example" content="test">';
}
add_action( 'wp_head', 'my_head_code' );

Если код должен выполниться до вывода шапки, смотрят на хук template_redirect. Он срабатывает раньше, чем WordPress подключает файл шаблона, поэтому его удобно использовать для перенаправлений и для отключения лишних вызовов. Для шапки в обычной ситуации достаточно хука wp_head, и каждый раз вписывать код в шаблон незачем.

Мета-теги версии и служебные ссылки: как удалить

Самые частые лишние строки в шапке WP - это несколько служебных тегов, которые ядро добавляет по умолчанию. Тег meta name=generator сообщает любому, кто открыл исходный код, с какой версией WordPress собран сайт. Ссылка RSD (Really Simple Discovery) нужна клиентам XML-RPC, а wlwmanifest_link выводит ссылку на манифест редактора Windows Live Writer. Короткую ссылку, то есть короткий URL записи, выводит wp_shortlink_wp_head.

Тег generator выводит функция wp_generator, подключённая к wp_head. Сам по себе он безвреден, но даёт любому готовый ориентир, какая версия ядра стоит на сайте, поэтому его обычно убирают первым. Так же поступаем с RSD, манифестом и shortlink: все эти теги живут на хуке wp_head и отключаются одинаково.

Отключение делается одной строкой на каждый тег. Код кладём в functions.php дочерней темы или в собственный плагин:

remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wp_shortlink_wp_head' );

Функция remove_action принимает имя хука и имя функции, и совпадение должно быть точным. Если callback добавлен с нестандартным приоритетом, одинарный вызов его не найдёт, и тогда третьим параметром передаём тот же приоритет. Для условного отключения, например только для посетителей сайта, оборачиваем вызов в if и делаем return, если это админка:

add_action( 'init', function () {
 if ( is_admin() ) return;
 remove_action( 'wp_head', 'rsd_link' );
} );

Что не следует удалять из заголовков сайта: rel=canonical, который указывает поисковику основную версию страницы, и подключения стилей и шрифтов темы, иначе вёрстка поедет. Отключение тегов, которые добавляет SEO-плагин, лучше делать через его настройки, а не через удаление строк кода: так эти теги не вернутся после обновления.

Что ещё можно убрать из шапки рядом с meta generator: ссылку feed_links на RSS, если сайт не публикует ленту, ссылку на REST API через rest_output_link_wp_head, если API сайту не нужен, и oEmbed-ссылки (oEmbed - протокол встраивания карточек в текст). Каждый пункт проверяем отдельно: плагины могут обращаться к REST API, а RSS нужен агрегаторам и подписчикам.

RSS, oEmbed, REST API и XML-RPC: что отключать

Помимо мета-тегов, в шапке WordPress по умолчанию есть ссылки, которые нужны не каждому сайту: на RSS-ленту, rel=prev и rel=next, oEmbed, REST API и XML-RPC. Одни ссылки просто занимают место, а другие держат работу плагинов, поэтому удалять их вслепую нельзя.

Ссылки на ленту выводит feed_links. Если сайт не публикует RSS и на него никто не подписан через агрегатор, эти теги лишние. Сама лента по адресу /feed/ при этом остаётся открытой, так что убрав ссылку из head, вы не закроете доступ к ней. Решение зависит от задачи сайта: если лента никому не нужна, тег можно убрать.

Ссылки rel=prev и rel=next выводит adjacent_posts_rel_link_wp_head. Google сообщал, что при индексации такие ссылки уже не учитывает, поэтому на большинстве сайтов тег можно убрать без последствий для выдачи. Оставить его не вредно, но пользы почти нет.

REST API нужен редактору блоков Gutenberg, мобильным приложениям и многим плагинам, которые читают посты через него. Ссылку на него выводит функция rest_output_link_wp_head. В старых разборах встречается название rest_output_link_header, это тот же механизм под другим именем, поэтому перед удалением смотрим, что реально выводится в исходном коде. Полностью выключать REST API опасно: редактор блоков начнёт выдавать ошибки.

XML-RPC - старый протокол на основе XML, через который работают некоторые мобильные клиенты и плагин Jetpack для удалённых подключений. Его часто отключают из-за атак перебором паролей, но полное отключение может сломать Jetpack. Перед тем как закрывать XML-RPC целиком, проверьте активные плагины. Если такой плагин есть, оставьте протокол включённым и закройте атаки другими средствами.

Ссылка X-Pingback - это HTTP-заголовок, а не тег в head, поэтому удаление из шапки её не уберёт. Pingback, то есть уведомления о ссылках между блогами, работает через тот же XML-RPC. Ссылки oEmbed и embeds (карточки видео и постов по ссылке) выводит wp_oembed_add_discovery_links. Если на сайте ничего не встраивается по ссылке, их можно убрать.

Перед удалением добавляем проверку: список плагинов и тем, которые ходят на REST API и XML-RPC, и опции SEO-плагина, где часть ссылок выключается без кода. Меняйте по одной ссылке и проверяйте сайт после каждого шага, иначе непонятно, какая строка всё сломала. Список ненужных тегов лучше составить до правки.

Emoji: скрипт и стили, которые грузятся на каждой странице

Emoji - это эмодзи, маленькие картинки-смайлики. WordPress поддерживает их с версии 4.2, и чтобы старые браузеры показывали их одинаково, ядро подключает на каждую страницу скрипт, который проверяет поддержку emoji, и встроенные в HTML стили (inline-стили). Оба подключения лежат в шапке, поэтому грузятся даже там, где смайликов нет вообще.

Скрипт выводит print_emoji_detection_script и подключает wp-emoji-release.min.js в head. Стили выводит print_emoji_styles через хук wp_print_styles. Отдельно есть wp_staticize_emoji_for_email: она заменяет emoji картинками в письмах и RSS-лентах, на обычной странице она не нужна.

Зачем это убирать: каждый лишний файл - это запрос и задержка до отрисовки. Если на сайте нет комментариев, форм или кнопки с эмодзи, подключение бесполезно. Для страниц без смайликов это лишние загрузки стилей и скриптов, а часть из них тянется с внешних адресов. При оптимизации скорости такие строки обычно удаляют первыми.

Отключаем обе части отдельными вызовами: скрипт с wp_head, стили с wp_print_styles. Этот хук используется ядром для вывода стилей. Если нужна чистота и в панели управления, те же функции снимаем с admin_print_scripts и admin_print_styles. Безусловное отключение удобно поставить на init, этот хук срабатывает до вывода шапки. Таблица ниже показывает всю цепочку.

После правки проверьте исходный код: wp-emoji-release там быть не должно. Текст с эмодзи выводится обычными символами, которые браузер покажет системным шрифтом. Для большинства сайтов это приемлемая цена за более быструю загрузку.

Удаление через functions.php и хуки: как не сломать сайт

Все правки сводятся к двум вызовам: add_action подключает функцию к хуку, remove_action её снимает. Чтобы отключение не сломало сайт, код держат в дочерней теме или в мини-плагине из одного файла. Мини-плагин удобнее: его функционал не привязан к теме, и при смене оформления отключение продолжает работать.

Главное правило: remove_action должен получить то же имя хука, то же имя функции и тот же приоритет, что и add_action. Если callback добавлен с приоритетом 7, а в remove_action передан приоритет по умолчанию, функция останется на месте и никакой ошибки не будет. Приоритет проверяем в исходном коде до того, как пишем удаление.

Если функции-обработчики оформлены как методы класса, в remove_action передаём массив, в котором указаны объект и имя метода. Для отключения по условию используем хук wp с проверкой is_page, а не init: на init условные функции ещё не знают текущую страницу, и is_page там всегда вернёт ложь. Пример ниже снимает скрипт emoji везде, кроме страницы с контактами.

add_action( 'wp', function () {
 if ( is_admin() ) return;
 if ( ! is_page( 'contacts' ) ) {
 remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
 }
} );

Чтобы убрать скрипт по его идентификатору (handle), сначала отключаем подключение: wp_dequeue_script снимает скрипт с конкретной страницы. Если он не нужен нигде, добавляем wp_deregister_script, и скрипт перестаёт регистрироваться. Базовые скрипты вроде jquery-migrate удаляйте осторожно: от них зависят другие.

Фильтры работают похоже, но меняют результат, а не снимают функцию. Вызов add_filter с __return_false подставляет ложь вместо решения, которое ядро принимает само. Например, add_filter( 'xmlrpc_enabled', '__return_false' ) закрывает XML-RPC целиком, и здесь снова вспоминаем Jetpack. Перед такой строкой проверяйте, что нужно сайту.

Если отключение зависит от настройки, значение читаем через get_option, а перед проверкой ключа массива используем isset, чтобы не получить ошибку на отсутствующем ключе. Так правка не падает, даже если опции ещё нет.

Типичная ошибка: строку поставили в functions.php, сайт сломался, и всё откатили разом. Тогда сразу видно, какая строка сломала сайт. Если после правки в консоли браузера появилась ошибка, вернитесь к строке, которую меняли последней.

Частые ошибки и как проверить результат

Самая частая ошибка - удалить не тот хук. Например, callback повесили на wp_head с приоритетом 7, а в remove_action передали другое имя функции. Ошибки при этом не видно: вызов молча ничего не делает, тег остаётся на месте, и кажется, что код не работает.

Вторая ошибка - править functions.php самой темы. При обновлении темы файл заменяется, строки пропадают без предупреждения, и тег возвращается. Поэтому код живёт в дочерней теме или в мини-плагине.

Третья ошибка - отключить всё подряд. Закрытие XML-RPC повышает безопасность, но если на сайте работает Jetpack, его удалённые подключения перестанут работать. REST API тоже лучше проверить до удаления.

Как проверить результат

1. Откройте страницу в браузере и нажмите Ctrl+U, чтобы увидеть HTML-код. Через Ctrl+F найдите теги generator, EditURI (это RSD), wlwmanifest и shortlink. Если поиск пуст, теги убраны.
2. Откройте инструменты разработчика (F12), вкладку Network, перезагрузите страницу и убедитесь, что скрипт wp-emoji-release.min.js больше не появляется.
3. Зайдите в админке в редактор записи и сохраните черновик. Если появилась ошибка, значит, убран нужный тег.

Главный тест - обновления. После обновления WordPress, темы и плагинов повторите все три шага, потому что обновления иногда возвращают хуки и меняют файлы. Не забывайте про кэш: плагин или кэш на сервере отдаёт старую страницу, и правка будет незаметна. Дополнительно откройте её в режиме инкогнито.

Плагин или код: Clearfy и выбор

Для WordPress выбор зависит от задачи. Если нужны готовые переключатели без программирования, берите плагин. Если нужен точный контроль над хуками, пишите код в дочерней теме. В коде ошибка дороже: неверная строка ломает сайт.

Код даёт точное управление: вы выбираете хук, приоритет и условие. Плагин Clearfy установлен на этом блоге, им можно чистить шапку без кода. На момент написания для этой задачи подходят такие опции: с помощью переключателей отключаются лишние скрипты, сервисы и служебные ссылки, базовая безопасность (смена страницы входа, лимит попыток входа, скрытие ошибок входа, отключение REST API) и минификация только HTML.

Честно: плагин закрывает не всё из этой статьи. Приоритеты хуков и условия, например отключение только на одной странице, через настройки не задать, и такая задача требует решения кодом.

Для полного набора опций есть платная версия (Pro). Что в неё входит, смотрите на странице плагина. Если типовых опций не хватает, остаётся код.

Итог: что убрать сразу и что оставить

Из шапки не стоит удалять ссылки rel=canonical и подключения стилей темы. Без стилей поедет вёрстка. Остальное делится на три группы: убрать, проверить и оставить.

1. Список ненужных тегов начинается с четырёх: generator, RSD, wlwmanifest и shortlink. Их можно убрать сразу, а generator к тому же раскрывает версию CMS.
2. Отключить emoji стоит, если на сайте нет комментариев и форм со смайликами. Вместе со скриптом уходят и стили emoji, и страница становится легче.
3. Перед удалением XML-RPC, REST API и RSS проверьте, кто их использует. Jetpack и редактор блоков ходят на эти адреса. Закрывать XML-RPC ради безопасности можно только после проверки. Решение о RSS принимайте по задаче сайта.
4. Оставить rel=canonical и стили темы в покое, даже если они выглядят лишними.
5. Вносить изменения по одной строке и проверять результат после каждого шага.

Главная ошибка, которой вы избежите, - ручная правка header.php без проверки. Все примеры выше строятся на remove_action.

Если разбираться самому не хочется, а задача одна и понятна, чистку шапки можно поручить исполнителю. На Kwork такие работы берут недорого, если описать, какие теги убрать.

Вывод: чистка шапки делается через remove_action в дочерней теме и проверяется в исходном коде, а не на глаз.

Данная статья основана на личном опыте автора и актуальна на момент публикации. Интерфейсы сервисов и алгоритмы поисковых систем регулярно меняются - рекомендую проверять актуальность инструкций на официальных ресурсах. Если у вас остались вопросы - задайте их в комментариях.

Список литературы

1. WordPress Developer Resources - developer.wordpress.org - «remove_action()»
2. WordPress Developer Resources - developer.wordpress.org - «wp_head» (action hook)
3. WordPress Developer Resources - developer.wordpress.org - «wp_generator()»
4. Google Search Central - developers.google.com - «How to specify a canonical URL with rel="canonical" and other methods»