Как удалить лишние мета-теги и служебный код из head WordPress

Если в исходном коде страницы WordPress в блоке <head> вы видите лишние мета-теги, ссылки на RSS, RSD, shortlink, emoji-скрипты и другой служебный код, это обычно не ошибка, а стандартные добавления ядра, темы или плагинов. Убрать их можно, но делать это нужно точечно: часть элементов действительно можно удалить без последствий, а часть лучше оставить, если ими пользуется тема, редактор или внешний сервис.

Ниже разберём, что именно обычно появляется в head, что можно безопасно отключить и как это сделать через код или плагин, не ломая сайт.

Что обычно можно убрать из head WordPress

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

• <meta name="generator" content="WordPress ...">;
• ссылки на RSS-ленты;
• wlwmanifest.xml для Windows Live Writer;
• rsd_link для удалённой публикации;
• shortlink;
• emoji-скрипты и стили;
• rel="prev" и rel="next" для архивов;
• wp-block-library и другие стили, если они не нужны конкретной теме или странице;
• лишние dns-prefetch и preconnect, которые добавляют плагины.

Не всё из этого стоит удалять. Например, wp-block-library может быть нужен, если на сайте используются блоки Gutenberg, а rel="prev" и rel="next" иногда полезны для навигации по архивам. Поэтому сначала стоит понять, что именно вы хотите убрать и зачем.

Безопасный способ: отключать только то, что не используется

Самый надёжный подход — не чистить head «под ноль», а убрать только те элементы, которые вам точно не нужны. Это особенно важно, если сайт работает на коммерческой теме, использует конструктор, SEO-плагин или нестандартную вёрстку.

Проще всего такие правки делать в дочерней теме или через небольшой функциональный плагин. Так изменения не пропадут после обновления темы.

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

Удаление стандартных мета-тегов и ссылок через functions.php

Ниже пример кода, который убирает самые распространённые служебные элементы WordPress из head. Его можно добавить в functions.php дочерней темы или в свой мини-плагин:

remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'wp_shortlink_wp_head', 10, 0);
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, 0);
remove_action('wp_head', 'wp_resource_hints', 2);

Что делает этот код:

• wp_generator убирает версию WordPress из мета-тега generator;
• rsd_link и wlwmanifest_link отключают старые служебные ссылки;
• wp_shortlink_wp_head убирает короткую ссылку страницы;
• feed_links и feed_links_extra удаляют RSS-ссылки;
• adjacent_posts_rel_link_wp_head убирает ссылки на соседние записи;
• wp_resource_hints отключает стандартные resource hints, но это стоит делать только если вы понимаете, что теряете.

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

Как убрать emoji-скрипты и стили

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

Добавьте такой код:

remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('admin_print_scripts', 'print_emoji_detection_script');
remove_action('wp_print_styles', 'print_emoji_styles');
remove_action('admin_print_styles', 'print_emoji_styles');

После этого WordPress перестанет выводить emoji detection script и связанные стили на фронтенде и в админке. Если у вас современный сайт и вы не полагаетесь на старое поведение WordPress с emoji, это обычно безболезненное изменение.

Как убрать лишние стили и скрипты, которые добавляет тема или плагин

Иногда проблема не в ядре WordPress, а в теме или плагине. В head могут попадать лишние стили, которые дублируют друг друга, или скрипты, которые нужны только на одной странице, но загружаются везде.

В этом случае удалять нужно не через remove_action, а через wp_dequeue_style() и wp_dequeue_script(). Для этого сначала нужно узнать handle файла — внутреннее имя, под которым он подключён.

Пример:

add_action('wp_enqueue_scripts', function () {
    wp_dequeue_style('plugin-style-handle');
    wp_dequeue_script('plugin-script-handle');
}, 100);

Здесь важно две вещи. Во-первых, код должен запускаться достаточно поздно, поэтому указывается приоритет 100. Во-вторых, удалять нужно только то, что вы точно идентифицировали. Если убрать не тот файл, можно сломать верстку, слайдер, форму или блоки темы.

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

Что лучше не удалять без проверки

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

• Canonical — обычно нужен для SEO и должен оставаться, если его не подменяет SEO-плагин.
• Open Graph и Twitter Card — это не ядро WordPress, а чаще мета-теги SEO-плагина; удалять их стоит только если вы точно не используете соцсети или управляете ими другим способом.
• wp-block-library — может быть нужен для блоков Gutenberg на фронтенде.
• Resource hints — иногда помогают, а не мешают.
• Стили и скрипты темы — удаляйте только после проверки, что страница не зависит от них.

Если задача — просто «сделать код чище», не стоит вырезать всё подряд. На практике лучше убрать только то, что вы понимаете и можете проверить после изменения.

Как проверить, что очистка head не сломала сайт

После правок откройте несколько типов страниц: главную, запись, страницу, архив, если он есть, и страницу с формой или блоками, которые зависят от скриптов. Затем проверьте:

• не исчезли ли стили темы;
• не сломались ли меню, слайдеры, выпадающие блоки и формы;
• не появились ли ошибки в консоли браузера;
• не пропали ли важные мета-теги, которые добавляет SEO-плагин;
• не изменился ли вывод на мобильных устройствах.

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

Когда удобнее использовать плагин вместо ручного кода

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

Например, Clearfy Pro подходит для типовой очистки WordPress от лишних мета-тегов, дублей и служебных элементов. Это не отменяет необходимости проверять результат, но снижает риск ошибки при ручной правке. Такой вариант особенно полезен владельцам сайтов, которые не хотят поддерживать собственный набор сниппетов в теме.

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

Практический порядок действий

Если нужно быстро и без лишних экспериментов, действуйте так:

1. Откройте исходный код страницы и выпишите, что именно хотите убрать.
2. Проверьте, не относится ли этот элемент к SEO-плагину, теме или блоку Gutenberg.
3. Сделайте резервную копию.
4. Добавьте точечное отключение через remove_action или wp_dequeue_*.
5. Очистите кэш.
6. Проверьте главную, записи и страницы, где используются важные элементы темы.

Такой порядок обычно безопаснее, чем попытка «почистить head целиком». В WordPress это почти всегда вопрос точечной настройки, а не тотального удаления всего служебного кода.