Как скрыть тот факт, что сайт использует WordPress?

Часто упускают один важный момент — удаление файла readme.html в корне WordPress. Этот файл не только идентифицирует установку как WordPress, но и содержит точную версию системы. И не забывайте повторять это действие после обновлений.

Связанный вопрос: Как запретить доступ или автоматически удалять readme.html, license.txt, wp-config-sample.php

Единственно верный ответ: НЕВОЗМОЖНО

Так много ответов с высокими рейтингами... пора внести ясность. Правда в том, что это практически невозможно, и даже если возможно, жизнь, вероятно, слишком коротка, чтобы тратить усилия на это. Любой ответ, предлагающий шаги для скрытия WordPress, просто тратит ваше время и вводит вас в заблуждение, заставляя думать, что вы скрыли WordPress (что абсурдно).

1) Проблема не в очевидных URL-адресах wp-*, мета-теге генератора и т.д. Главные проблемы связаны с паттернами, характерными для WordPress, которые самописная система не станет реализовывать, например: страницы авторов, страницы с датами (год/месяц/день), использование параметра p=nnn, форма комментариев с классами, структурой и названиями ссылок WordPress, а также самореклама плагинов кеширования и Yoast SEO (и, вероятно, многих других плагинов), которую можно увидеть только при анализе HTML.

2) Существуют и другие бесчисленные способы, выдающие использование WordPress (и с ними ничего не поделать):

• Даже заголовки ответа PHP (как отметил Dan Gayle в комментариях ниже) содержат специфичный для WordPress заголовок.

• Любой может запросить десятки корневых .php-файлов: site.com/wp-cron.php или site.com/xmlrpc.php (и т.д., которые невозможно скрыть), и в ответе будет статус 200, а не 404 not found.

• Любой может проверить JSON-эндпоинты и получить специфичный для WordPress ответ.

• В HTML страницы многие файлы .css или .js содержат фразы, явно указывающие на WordPress.

• В HTML страницы легко найти элементы/классы CSS, например <div class="entry-content post-14"... и т.д. (что прямо указывает на структуру WordPress).

• В HTML страницы легко заметить папку uploads, или даже если её переименовать через хардкод, то часть с датой, например uploads/2018/05/image.jpg (или даже image-315x225.jpg), выдаст типичную структуру WordPress.

• Так как многие сайты теперь построены на Multisite, в ссылках используется, например, /site/2...

• Запрос к readme-файлам плагинов/тем (которые есть у всех): например, plugin-name/readme.txt, возвращает статус 200.

• И множество, множество, множество других вещей, которые вы (или даже профессионалы) не сможете скрыть и только потратите дни впустую!

Вывод

Даже если вы приложите усилия, чтобы убрать все признаки WordPress, вам, возможно, придётся переделывать или хотя бы перепроверять всё после каждого обновления плагинов или ядра. Жизнь слишком коротка для этого.

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

Единственное, о чём стоит заботиться — максимально защитить WordPress и следить за регулярными обновлениями.

Я всегда использовал метод Roots Theme.
Но применение его к тем ThemeJungle темам обычно вызывает сильную головную боль.

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

^{/m — это папка uploads, /t — папка themes, а /t/t — папка активной темы. Сайт не сложный, поэтому загружается мало ресурсов...}

WP_CONTENTLESS

wp-config.php

Устанавливаем wp-content в корень сайта (/public_html/).

/** 
 Внутри WP_CONTENT должны быть следующие папки: 
 /languages, /mu-plugins, /plugins, /themes, /upgrade, /uploads  

 Определения WP_CONTENT_* ниже УДАЛЯЮТ существование папки /wp-content 
 и размещают её содержимое в КОРНЕ сайта

 КРАЙНЕ важно соблюдать осторожность при обслуживании файлов на сервере (например, обновления WP, смена администратора...), 
 так как папки Тем и Плагинов переименованы в /t и /p (они могут быть случайно удалены)

 ОБРАТИТЕ ВНИМАНИЕ:
 - мы меняем папку Плагинов в определениях WP_PLUGIN_*
 - папка Тем изменяется через MustUse-плагин 
   (/mu-plugins/set-extra-themes-folder.php)
 - папка Uploads изменяется в настройках WordPress 
   (http://example.com/wp-admin/options-media.php)
 - жёсткий путь для WP_CONTENT_DIR и WP_PLUGIN_DIR можно проверить с помощью действия внутри плагина set-extra-themes-folder (см. комментарии в этом файле)
*/
define( 'WP_CONTENT_DIR', '/www/htdocs/username/public_html' );
define( 'WP_CONTENT_URL', 'http://www.example.com' );

define( 'WP_PLUGIN_DIR', '/www/htdocs/username/public_html/p' );
define( 'WP_PLUGIN_URL', 'http://www.example.com/p' );

Я спросил об этом в [wp-hackers] - Any drawbacks in setting WP_CONTENT_DIR (and URL) to DOCUMENT_ROOT?, где John Blackbourn¹, Mike Little² и Otto³ любезно поделились советами:

^{1
Я использую такую структуру на сайте уже 18 месяцев и не заметил никаких проблем. Как и при любом изменении расположения папки контента, нужно проверять, что плагины не предполагают, что папка контента находится в wp-content.}

^{2
В сети обсуждается, что $_SERVER['DOCUMENT_ROOT'] может быть уязвим для взлома. В этом случае это крайне опасно, потому что есть много мест, где используется require() или include() с WP_CONTENT_DIR 'something';}

^{3
Бывают случаи, когда содержимое $_SERVER может быть безопасным, но в целях безопасности лучше всегда считать его ненадёжными данными. В данном случае лучше жёстко прописать путь.}

Новая папка тем

/mu-plugins/set-extra-themes-folder.php

Поскольку констант WP_THEMES_* не существует, нам нужна функция register_theme_directory(), чтобы "Зарегистрировать директорию, содержащую темы."
Попытка установить дополнительную директорию в корень даёт забавные результаты (т.е. не работает).

<?php
/*
    Plugin Name: Set Extra Themes Folder
    Version: 1.0
    Description: Позволяет использовать директорию - http://example.com/t - как дополнительную папку тем
    Plugin URI: http://wordpress.stackexchange.com/questions/1507
    Author: brasofilo
    Author URI: http://rodbuaiz.com
*/


/**
 * Удалите комментарий со следующей строки, чтобы узнать правильный путь для register_theme_diretory()
*/
//add_action( 'admin_head', 'brsfl_alert_directory_path' );

function brsfl_alert_directory_path()
{
    echo '<script type="text/javascript">
        alert("Directory: '.$_SERVER['DOCUMENT_ROOT'].'");
    </script>';
}


/**
 * Следующий код позволяет использовать папку "t" как ДОПОЛНИТЕЛЬНУЮ директорию тем
*/
register_theme_directory( '/www/htdocs/username/public_html/t' );


/**
 * Отмена регистрации стандартных скриптов в wp-includes для CDN-версий
*/
add_action('init', 'brsfl_init_scripts');

function brsfl_init_scripts() 
{
    if ( !is_admin() ) 
    {
        wp_deregister_script( 'jquery' );
        wp_deregister_script( 'swfobject' );
        wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', false, '1.7.1' );
        wp_register_script( 'swfobject', 'https://ajax.googleapis.com/ajax/libs/swfobject/2.2/swfobject.js', false, null, true );
        wp_enqueue_script( 'jquery' );
        wp_enqueue_script( 'swfobject' );
    }
}

Папка загрузок

/wp-admin/options-media.php

Вместо http://example.com/uploads будет использоваться http://example.com/m.
Если снять галочку Организовать мои загрузки в..., URL-адреса ресурсов будут выглядеть более WPless.
Если сайт уже работает, необходимо выполнить поиск/замену в базе данных и переместить файлы.

Плагины и содержимое head

См. ответ Cris_O в этом Q&A.

Readme.html

См. ответ Rarst в этом Q&A.

Другие шаги

Как обычно, темы ThemeJungle могут потребовать специфических исправлений.
Например... TimThumb не работает (!!!лол!!!).

Вы можете разместить WordPress на одном сервере, а контент получать с другого сервера, включая только нужные вам материалы.

Если вам нужен RSS, вам придется делать то же самое и с ним.

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

Вы также можете использовать JavaScript-систему комментариев, такую как Disqus.

Очень низкое потребление ресурсов, так как на сервере, обслуживающем контент, нет баз данных.

Вы можете создать собственный адрес для входа в свой блог. Вместо использования стандартного пути "myblog.com/wp-admin" для доступа к панели управления, эта страница поможет вам создать скрытые логины, что также полезно для мер безопасности.

Так что люди, которые добавляют wp-admin к вашему блогу, не смогут угадать :)

Помимо вышеперечисленного, необходимо заблокировать доступ к различным файлам и директориям wp*. Если кто-то захочет проверить, используете ли вы WordPress, он может попытаться угадать наличие файла wp-settings.php или доступ к некоторым директориям. Возврат ошибки 403 недостаточен, так как это сообщает пользователю, что ресурс существует; просто у него нет доступа к нему.

Я не являюсь экспертом по Apache, поэтому задал этот вопрос на serverfault.

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

$ curl -I http://www.rollingstones.com/
Server: WP Engine/5.0

$ curl -I http://www.mattcutts.com
X-Powered-By: W3 Total Cache/0.9.1.3

$ curl -I http://blogs.reuters.com/us/
WP-Super-Cache: Served supercache file from PHP

Некоторые из этих заголовков устанавливаются сервером, другие — плагинами, поэтому нет единого способа полностью их удалить. Однако если вы используете PHP 5.3, вы можете применить функцию

header_remove("X-Foo"); (http://www.php.net/manual/ru/function.header-remove.php)

для удаления известного PHP-заголовка перед отправкой контента. Я не могу с уверенностью сказать, куда именно вставить этот код (возможно, кто-то дополнит эту информацию), но, скорее всего, безопаснее всего разместить его в самом верху файла index.php ДО любого контента, который отправляется в браузер.

Это может быть сложно реализовать, если вы новичок в php и mod_rewrite. Рекомендую ознакомиться с соответствующей частью моего ответа. Или попробуйте сами, вы можете использовать что-то подобное, чтобы скрыть структуру пути wp-content/plugins:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^modules/(.*) /wp-content/plugins/$1 [L,QSA]
</IfModule>

Это изменит путь на /modules. Используйте нечто подобное для других структур, вам могут понадобиться более продвинутые правила перезаписи, дополнительную информацию о mod_rewrite можно найти по ссылке http://httpd.apache.org/docs/current/mod/mod_rewrite.html.

Если предпочитаете готовые решения, есть несколько хороших плагинов, как коммерческих, так и бесплатных в репозитории WordPress, рекомендую попробовать WP Hide & Security Enhancer. Он включает множество функций и помогает изменить практически всё, чтобы сделать ваш WordPress неузнаваемым. Вот некоторые возможности кода:

• Пользовательский URL админки
• Заблокировать стандартный URL админки
• Блокировка прямого доступа к папкам для полного скрытия структуры
• Пользовательское имя файла wp-login.php
• Блокировка стандартного wp-login.php
• Блокировка стандартного wp-signup.php
• Блокировка XML-RPC API
• Новый путь XML-RPC
• Настраиваемый URL темы
• Новый URL дочерней темы
• Изменение имени файла стилей темы
• Пользовательский wp-include
• Блокировка стандартных путей wp-include
• Блокировка стандартного wp-content
• Пользовательские URL плагинов
• Индивидуальное изменение URL плагинов
• Блокировка стандартных путей плагинов
• Новый URL загрузок
• Блокировка стандартных URL загрузок
• Удаление версии WordPress
• Блокировка Meta Generator
• Отключение emoji и связанного javascript кода
• Удаление тега pingback
• Удаление Meta wlwmanifest
• Удаление Meta rsd_link
• Удаление wpemoji

и многое другое..

Я не хочу повторять варианты кодирования, так как они уже были подробно рассмотрены. Другой известный мне вариант, который работает – это использование плагина для скрытия wp. Я уже использовал этот плагин с удовлетворительными результатами. Он называется Hide My WordPress.

Большинство ответов сосредоточены на сокрытии WordPress в исходном коде страницы, но еще до этого стандартная установка WP выдает себя в HTTP-заголовках. Протестируйте свой сайт на сервисе вроде web-sniffer (эмулируя IE 6 и запрашивая HTTP 1.0 заголовки), и вы увидите среди прочего:

<http://www.example.com/wp-json/>; rel="https://api.w.org/"

Это ссылка на API Wordpress.org. Она появляется с момента включения REST API в WP 4.4. Удалить её можно этой строкой в начале файла functions.php:

remove_action( 'template_redirect', 'rest_output_link_header', 11, 0 );

Многие плагины, например Jetpack для своих коротких ссылок, также могут добавлять ссылки в HTTP-заголовки. Они могут это делать благодаря HTTP API WordPress, который позволяет манипулировать заголовками. Вы можете использовать этот интерфейс для удаления всех настроек заголовков от плагинов, если добавите своё действие достаточно поздно в процессе.

Наконец, вы можете использовать интерфейс заголовков .htaccess для перехвата действий WordPress. Например, можно запретить отправку любых Link-заголовков, добавив эти строки:

<IfModule mod_headers.c>
Header unset Link
</IfModule>

Вы можете настроить тему, чтобы исключить всю информацию о WordPress. Также удалите мета-виджет и любые другие виджеты, которые выводят информацию о платформе.

Лично я предпочитаю выражать благодарность, указывая, что использую WordPress.

Вы можете использовать плагин WPS Hide Login.
По умолчанию вход в WordPress осуществляется через wp-admin. Но с этим плагином вы можете изменить wp-admin на любой другой адрес.

Пример:

До: http://example.com/wp-admin
После: http://example.com/custom-text-to-login