oEmbed в WordPress удобен, пока вы не начинаете смотреть на исходный код страницы и сетевые запросы. На обычном сайте он добавляет лишние обращения к wp-embed.min.js, а в некоторых сценариях — еще и служебные запросы, которые не дают заметной пользы, если вы не вставляете внешние материалы через автоподстановку.
Если задача простая — убрать этот слой без поломки контента — лучше отключать oEmbed точечно, а не вырезать все подряд из functions.php. Ниже разберем, что именно отключать, как проверить результат и где чаще всего ошибаются.
Когда oEmbed действительно мешает
Проблема обычно всплывает не в админке, а на фронтенде: лишний JavaScript, дополнительные HTTP-запросы, ненужные стили или автоподгрузка встроенных материалов, которые на сайте не используются. Это особенно заметно на проектах, где контент собирается вручную, а внешние видео, посты и твиты вставляются через обычный HTML или блоки редактора.
Типичные признаки:
- в исходнике страницы есть
wp-embed.min.js, хотя автоподстановки не нужны; - в DevTools видно лишний запрос к скрипту WordPress;
- в PageSpeed/анализе производительности всплывает небольшой, но постоянный хвост от встроенного embed-механизма;
- редакторы вставляют ссылки, а WordPress автоматически превращает их в встраиваемые блоки, что не всегда нужно.
Диагностика: что именно включено на сайте
Сначала проверьте, действительно ли oEmbed используется. Не все отключения безопасны: если редакция вставляет ссылки на YouTube, X, WordPress.org или другие поддерживаемые сервисы и рассчитывает на автоподстановку, полное отключение изменит поведение контента.
Проверка в исходном коде
Откройте страницу сайта и найдите в HTML строку wp-embed.min.js. Если она есть, скрипт подключается на фронтенде. Дополнительно посмотрите, нет ли в контенте блоков, которые завязаны на oEmbed: например, вставок ссылок, превращающихся в карточки.
Проверка в редакторе
Если при вставке ссылки WordPress автоматически подменяет ее на embed-блок, значит механизм активен и влияет не только на фронтенд, но и на процесс редактирования. В этом случае отключение нужно согласовать с редакцией: иногда проще оставить oEmbed в админке, но убрать его с публичной части.
Как отключить oEmbed в WordPress: рабочий вариант
Самый предсказуемый путь — убрать фронтенд-скрипт и отключить автоконвертацию ссылок в embed. Для этого можно использовать код в дочерней теме или в небольшом mu-plugin. Второй вариант надежнее: он не зависит от темы и не потеряется при обновлении.
<?php
/**
* Plugin Name: Disable oEmbed frontend
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
// Убираем скрипт oEmbed с фронтенда.
add_action( 'wp_enqueue_scripts', function () {
wp_deregister_script( 'wp-embed' );
}, 100 );
// Отключаем автоподстановку oEmbed по ссылке в контенте.
remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );
remove_filter( 'widget_text_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );
remove_filter( 'widget_block_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );
// Убираем discovery-ссылки из head.
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
Если вам не нужен только фронтенд-скрипт, а автоподстановка в контенте должна остаться, уберите только первую часть с wp_deregister_script( 'wp-embed' ). Это более мягкий сценарий.
Если нужен только частичный контроль
Иногда достаточно отключить oEmbed на публичной части, но оставить его в редакторе для контент-менеджеров. Тогда не трогайте фильтры autoembed, а снимите только подключение скрипта и discovery-ссылки. Это снижает риск сломать старые записи.
| Подход | Что отключает | Риск | Когда выбирать |
|---|---|---|---|
| Плагин для оптимизации | Часть лишних скриптов и настроек | Зависимость от стороннего интерфейса | Если нужен быстрый результат без кода |
| Код в mu-plugin | Только нужные элементы oEmbed | Нужна аккуратность при обновлениях | Если нужен точный контроль |
| Ничего не отключать | Ничего | Лишняя нагрузка и автоподстановки | Если oEmbed реально используется редакцией |
Пошаговое решение без поломки контента
- Сделайте резервную копию файлов и базы.
- Проверьте, используются ли embed-блоки в старых записях.
- Добавьте код в mu-plugin или дочернюю тему.
- Очистите кеш страницы, объектный кеш и CDN, если они есть.
- Откройте несколько страниц с разным типом контента и проверьте результат.
Если на сайте есть кастомные шаблоны, убедитесь, что они не подключают wp-embed вручную. Иногда скрипт возвращается через тему или плагин, и тогда отключение в одном месте не дает эффекта.
Как проверить, что решение сработало
Проверка должна быть не на глаз, а по фактам. Смотрите три вещи: исходный код страницы, поведение редактора и сетевые запросы в браузере.
- в исходнике больше нет
wp-embed.min.js; - в
<head>отсутствуют discovery-ссылки oEmbed; - при вставке обычной ссылки WordPress не превращает ее в embed, если вы отключали и автоподстановку;
- в DevTools на вкладке Network нет запроса к
wp-embed.min.js; - старые записи отображаются так же, как и до изменений, если вы не трогали автоконвертацию контента.
Если используете кеширующий плагин, обязательно проверьте страницу в режиме инкогнито или после полной очистки кеша. Иначе можно увидеть старую версию и сделать ложный вывод, что код не сработал.
Частые ошибки и как их исправить
Удалили скрипт, но автоподстановка осталась
Это нормальная ситуация, если вы отключили только wp-embed. Скрипт и автоподстановка — не одно и то же. Если нужно убрать оба механизма, отключайте и фильтр autoembed.
Сломались старые записи с встраиваниями
Так бывает, если контент рассчитывал на автоматическую обработку ссылок. Проверьте, не были ли вставлены ссылки без iframe-кода. Если да, лучше вернуть автоподстановку или вручную заменить проблемные блоки на статический HTML.
Изменения сделали в теме, а после обновления все пропало
Код в теме — временное решение. Для системных правок используйте mu-plugin или отдельный мини-плагин. Это особенно важно, если сайт обновляется регулярно и на нем несколько разработчиков.
Очистили только кеш страницы
Если есть CDN, серверный кеш или объектный кеш, одного действия недостаточно. После изменения oEmbed проверьте все уровни кеширования, иначе на части пользователей останется старая версия страницы.
Что учесть по безопасности и производительности
Само отключение oEmbed не делает сайт безопаснее в широком смысле, но уменьшает количество лишнего кода на фронтенде и упрощает контроль за тем, что именно загружается на странице. Для производительности это полезно только в рамках общей чистки: один скрипт не спасает тяжелую тему, но помогает убрать накопившийся технический шум.
Если вы уже занимаетесь чисткой WordPress, имеет смысл смотреть на связанные вещи: лишние эмодзи, ненужные стили редактора, дубли в head, старые интеграции. Для этого обычно удобнее собирать правки в одном месте, а не размазывать их по шаблонам. В проектах, где нужен более широкий набор настроек для SEO и технической чистки, иногда используют Clearfy Pro, но только если реально нужен набор функций, а не один конкретный фикс: https://wpshop.ru/plugins/clearfy.
Когда oEmbed лучше не отключать
Если редакция активно вставляет внешние материалы через обычные ссылки и рассчитывает на автоматическое преобразование, полное отключение создаст лишнюю ручную работу. В таком случае лучше ограничиться удалением фронтенд-скрипта только на тех типах страниц, где embed-функции не используются, или оставить все как есть до пересмотра контент-процессов.
Практический критерий простой: если после отключения вы начинаете вручную чинить десятки записей, значит решение выбрано слишком грубо. Тогда стоит вернуться к частичному отключению и проверить, где именно oEmbed приносит пользу, а где только создает шум.