Если открыть исходный код страницы WordPress, там часто видно лишнее: версию движка, служебные ссылки, RSD, shortlink, oEmbed, emoji-скрипты, мета-теги для админки и другие элементы, которые обычному сайту не нужны. Часть из них можно убрать без вреда для работы сайта, а часть лучше не трогать, если вы не понимаете, зачем она нужна.
Ниже — практический разбор: что именно можно скрыть, где это делается и как не сломать тему, редактор или интеграции.
Что обычно считается лишними мета-данными WordPress
Под «мета-данными» в контексте WordPress обычно имеют в виду не только тег <meta>, но и весь служебный код, который движок автоматически добавляет в <head> и иногда в футер. На типичном сайте туда попадают:
<meta name="generator" content="WordPress ...">— показывает версию WordPress;- RSD-ссылка для старых внешних редакторов;
- WLW Manifest — наследие Windows Live Writer;
shortlink;- emoji-скрипты и стили;
- oEmbed-ссылки и связанные с ними скрипты;
- ссылки на REST API в
<head>; - пингбэк-ссылка
rel="pingback"; - стандартные мета-теги вроде
wp-site-verification, если они вам не нужны в конкретном виде.
Не всё из этого стоит удалять. Например, версия WordPress в генераторе — это скорее косметика и небольшой плюс к скрытности, но не полноценная защита. А вот отключение oEmbed или emoji может быть оправдано, если вы не используете эти функции и хотите сократить лишние запросы.
Что можно убрать без заметного риска
Для обычного сайта чаще всего безопасно убрать именно следующий набор:
- мета-тег генератора WordPress;
- RSD и WLW Manifest, если вы не подключаете внешние редакторы старого типа;
shortlink, если вам не нужен короткий URL в исходнике;- emoji-скрипты и стили, если вы не хотите поддержку старых сценариев отображения эмодзи;
- oEmbed-ссылки, если вы не используете встраивание контента WordPress в сторонние сайты и наоборот;
- pingback, если вы не используете pingback как механизм уведомлений;
- ненужные стандартные стили и скрипты, которые тема или плагины не используют.
С осторожностью относитесь к удалению REST API и связанных ссылок. Сам API нужен не только для внешних интеграций, но и для редактора блоков, некоторых плагинов и современных функций WordPress. Полностью отключать его ради «чистого HTML» обычно не стоит.
Как убрать служебные мета-данные через functions.php
Самый прозрачный способ — добавить код в functions.php дочерней темы или в собственный мини-плагин. Так вы контролируете, что именно отключаете, и не зависите от стороннего плагина.
Перед изменениями сделайте резервную копию файлов темы. Если вы редактируете functions.php основной темы, обновление может затереть правки. Для постоянного решения лучше использовать дочернюю тему или отдельный плагин.
Ниже пример, который убирает наиболее распространённые служебные элементы из <head>:
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'wp_shortlink_wp_head', 10);
remove_action('wp_head', 'feed_links', 2);
remove_action('wp_head', 'feed_links_extra', 3);
remove_action('wp_head', 'adjacent_posts_rel_link_wp_head', 10);
remove_action('wp_head', 'rest_output_link_wp_head', 10);
remove_action('wp_head', 'wp_oembed_add_discovery_links', 10);
remove_action('wp_head', 'wp_oembed_add_host_js');
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
remove_action('wp_head', 'rel_canonical');Этот набор не универсален для всех сайтов. Например, удаление feed_links и feed_links_extra имеет смысл только если вы точно не используете RSS-ленты. А rel_canonical лучше не убирать без понимания последствий: канонический URL помогает поисковым системам и обычно должен оставаться.
Поэтому практичнее использовать не «всё подряд», а точечную очистку. Если задача — только скрыть версию WordPress и убрать мелкий служебный шум, достаточно начать с генератора, RSD, WLW, shortlink и emoji.
Что лучше не удалять без необходимости
Есть элементы, которые часто путают с мусором, хотя они полезны или даже критичны в некоторых сценариях:
- canonical — нужен для нормальной индексации и борьбы с дублями;
- REST API — используется редактором блоков и многими плагинами;
- wp-json-ссылки и связанные endpoint'ы — могут быть частью работы темы и интеграций;
- стили и скрипты плагинов — если удалить их «на глаз», можно сломать форму, слайдер, меню или блоки;
- мета-теги верификации — если они нужны для Google Search Console, Яндекс.Вебмастера и других сервисов, их нельзя просто вычищать из шаблона.
Если цель — не «почистить всё», а убрать именно лишнее, ориентируйтесь на то, что не влияет на контент, SEO и функциональность сайта. Служебный код, который нужен для работы редактора, форм или интеграций, лучше оставить.
Как скрыть версию WordPress в HTML и в файлах
Удаление wp_generator убирает версию из мета-тега в <head>, но версия может всплывать и в других местах: в путях к CSS и JS, в комментариях темы, в readme-файлах плагинов, в заголовках HTTP. Полностью «спрятать WordPress» только одной строкой кода нельзя.
Если вам нужно именно уменьшить видимость версии в исходнике, обычно делают три вещи:
- убирают
wp_generator; - не оставляют в публичной папке файлы вроде
readme.html, если они есть; - следят, чтобы тема и плагины не добавляли версию в query string без необходимости.
Но здесь есть нюанс: версия в параметрах CSS/JS иногда помогает обходить кэш после обновлений. Если вы удалите её вручную, браузер и CDN могут дольше держать старые файлы. Поэтому не стоит бездумно вырезать все упоминания версии из URL ресурсов.
Как проверить, что лишний код действительно исчез
После правок откройте страницу сайта в браузере и посмотрите исходный код через Ctrl+U или через инструменты разработчика. Ищите конкретные строки, которые вы удаляли: generator, rsd_link, wlwmanifest, shortlink, emoji-скрипты, oEmbed-ссылки.
Удобно проверять не только главную страницу, но и запись, страницу и архив. В WordPress часть кода может выводиться на одних типах страниц и не выводиться на других.
Если вы используете кэш-плагин или серверный кэш, очистите его после изменений. Иначе вы можете смотреть на старую версию HTML и решить, что код не удалился.
Ещё один практичный способ — поиск по исходнику. Если нужная строка не находится, а страница открывается без ошибок, значит изменение сработало. Если после правки сайт начал вести себя странно, верните изменения и отключайте элементы по одному, чтобы понять, что именно было лишним.
Когда удобнее использовать плагин, а не код
Если вы не хотите править тему вручную, проще использовать плагин, который умеет чистить служебные элементы WordPress. Это удобно, когда нужно быстро убрать несколько стандартных мета-данных без редактирования файлов и без риска потерять изменения при обновлении темы.
Такой подход особенно полезен для владельцев сайтов, которые не хотят держать собственный код в functions.php. Но и тут важно смотреть, что именно отключает плагин: некоторые решения убирают слишком много сразу, а вам нужен только аккуратный минимум.
Если у вас уже стоит плагин для оптимизации и чистки WordPress, проверьте его настройки перед установкой ещё одного инструмента. Дублирующие плагины часто конфликтуют между собой: один удаляет скрипт, другой пытается его снова добавить, и в итоге вы получаете нестабильное поведение.
Практический минимум для большинства сайтов
Если нужен короткий и безопасный набор действий, я бы начинал так:
- убрать
wp_generator; - удалить RSD и WLW Manifest, если они не используются;
- скрыть
shortlink; - отключить emoji-скрипты и стили, если они не нужны;
- не трогать canonical и REST API без явной причины;
- после правок проверить исходный код и очистить кэш.
Этого обычно достаточно, чтобы убрать из HTML лишнюю служебную информацию и сделать код страницы аккуратнее, не ломая сайт. Если же вам нужна более глубокая чистка, сначала проверьте, какие именно элементы добавляет тема и какие из них действительно используются на вашем проекте. В WordPress «удалить всё лишнее» и «удалить всё подряд» — это разные задачи, и вторая почти всегда заканчивается проблемами.