VPS от Океана тут просто избыточна.
С таким сайтом при внешнем CDN-кеше, хостинг для вас значения уже почти не будет иметь в любом случае.
Поэтому полностью достаточно вообще любого виртуального хостинга. Даже среди РФ\СНГ-хостеров найдёте огромное количество подходящих вариантов в пределах 1.5-2$.
Для ваших целей на старте у нас подойдёт даже бесплатный тариф. Он уже будет быстрее большинства альтернатив, как минимум, по РФ\СНГ.
И совсем необязательно отказываться от CMS, поскольку основное преимущество - в возможностях действительного гибкого кеширования динамического контента.
Выделенные IP'ы доступны, но на практике мало актуальны (кроме разделения собственных сайтов одной тематики). Т.к. вопросы РКН-блокировок учитываются, а потенциально рискованные соседи отселяются превентивно.
* Как и с Клаудом, хостинг вам всё равно потребуется.
- Заблокируйте по User-Agent в htaccess. Зачем по ИП-адресу, когда он честно представляется.
- Оптимизируйте производительность сайта - это не нормально то, что сайт грузит один только Ahrefs. Скорее всего, это всё равно в итоге потребуется.
iThemes Security - не панацея, но он автоматически применяет ряд блокировок, подобных тем, что вы сейчас прописываете в htaccess, и действительно может немного помочь хотя бы сэкономить время.
По htaccess. Не только содержимым GET-запросов ломают. Если вы хотите что-то нафильтровать по ним, то писать придётся ещё много, а результат всё равно будет далёк от желаемого.
Одна из не универсальных, но действительно надежных методик - белые списки на всё потенциально опасное.
Просто заблокировать в htaccess или на файрволе POST-запросы и запросы с не-пустым QUERY_STRING для всех адресов вообще, исключая белый список (или конкретные QS).
На большинстве WP-сайтов белый список на практике получается очень скромным (скрипт комментариев, формы заявок, пользовательские аяксы).
А системные папки сделать открытыми только для себя (блокировкой по IP-адресу или HTTP-авторизации).
Для современных Вордпрессов нет большого смысла, но для многих не лишнее поудалять до попадания в CMS заголовки User-Agent \ X-Forwarded-For, если не используются.
С тем, что никакая защита не абсолютна, мы на практике сочетаем комплекс решений:
1) Внешний файрвол - для реализации подобных блокировок, только в более удобном и эффективном виде, чем через htaccess
2) Лёгкие бэкапы - позволяют делать "снимки" хоть каждый час
3) Антивирус - автоматически проверяет каждый бэкап и высылает уведомления
4) Подробный контроль всех изменений - если антивирус не определил проблему, то всё равно будет видно добавление\изменение потенциально опасных файлов
Ещё ряд дополнительных модулей оптимизирует ситуацию. Но уже эти позволяют главное - и защитить, и, в случае прорыва, сразу узнать о проблеме да почти моментально вылечить сайт.
Есть существенная вероятность того, что вы не совсем корректно определили причину данной проблемы.
Может быть изменение кодировки в http-заголовках. Для начала попробуйте хотя бы просто явно указать её в html, если нету.
Либо просто воспользуйтесь нашим решением, которое не требует интеграции с плагинами и гарантированно обеспечит намного бОльшую скорость и экономию нагрузок.
1. Согласно аналитике MOZ - в Гугле есть незначительное прямое влияния параметра Time To First Byte (т.е. момента начала загрузки).
2. По другим исследованиям MOZ, а также статистике Амазона скорость влияет на конверсию.
Из-за связи с общим комфортом посетителя и возможностью его быстрее "зацепить".
Для поисковых систем ваша конверсия связана с параметрами, которые учитываются в рамках расчета Поведенческих Факторов.
3. Аптайм по аналогии имеет то же значение для посетителей, только более выраженное.
В том числе, и из-за того, что во время неработоспособности сайта практически все посетители с поиска становятся "отказами".
4. Пауки Гугла и других ПС имеют алгоритмы для расчета максимальной интенсивности индексации сайта.
Так делается, чтобы минимизировать шансы перегрузки сайтов из-за недостатка ресурсов.
Поэтому из-за появления медленных или ошибочных запросов сама индексация тоже может замедляться.
Как и в случае, если вы были вынуждены вручную ограничить скорость индексации с помощью Crawl-Delay.
* В плане ошибок, помимо просто их искоренения не лишней может быть отдача заголовка "Retry-After" вместе с ними.
Он не очень популярен, но бот Гугла и некоторые другие его учитывают.
------
Влияние HTTPS - большинством оценивается как существующее, но не значительное и зависящее от типа сайта.
Как обязательную необходимость можно воспринимать для коммерческих проектов или любых других, где происходит взаимодействие с персональными данными посетителей (есть регистрация, возможности заказа, приёма заявок или подобное).
Точно очень значимое и объективное влияние есть в случаях, когда из-за форм браузеры подписывают HTTP-сайт в адресной строке как "Ненадёжный".
Эта коварная формулировка многими посетителями может быть воспринята как предупреждение об опасности самого сайта. Что имеет шансы подорвать доверие и, как следствие, конверсию и ПФ.
Обычные антивирусы - не лишнее на правах "дополнительной помощи". Но с такими проблемами нужно начинать разбираться всегда с помощью специализированных антивирусов для сайтов. Это совсем другие подходы. И у сайта есть не только файлы, но и БД.
Только комплексный подход может дать надёжные гарантии.
1. Жёсткая фильтрация запросов к сайту по типам, адресам и содержимому.
С помощью htaccess или файрвола.
Индивидуальная адаптация с подходом исключительного "белого списка" на POST-запросы, запросы с GET-параметрами - для многих может сразу дать 98+% эффективности.
Поскольку блокирует сами возможности для использования уязвимостей.
2. Исключение лишних данных из запросов.
Некоторые уязвимости используют неправильную обработку заголовков USER-AGENT, X-FORWARDED-FOR и некоторых других.
Большинству сайтов они не нужны и могут быть просто заранее вырезаны перед попаданием данных к CMS.
3. Минимально необходимые права на все файлы.
Некоторые уязвимости взломщик может использовать только, если одновременно есть проблемы с правами.
4. Готовность к тому, что возникнет ситуация, когда все защиты не сработали и взлом произошёл.
- Контроль работоспособности сайта
- Постоянные антивирусные сканирования файлов и БД
- Контроль за всеми изменениями в потенциально опасных файлах
- Внешний контроль за появлением редиректов, новых js-вставок и исходящих ссылок
- Обеспечение возможности быстро восстановиться после проблем из резервной копии
5. Постоянное обновление CMS, плагинов и сопутствующих скриптов - разумеется, тоже помощь.
Но, как и отслеживание багтрекеров, - это требует постоянной ручной работы, в результате чего является самым дорогим методом.
Который в полноценном виде доступен только достаточно крупным проектам.
А для стандартных, в основном, используется после взлома.
Разницы нет никакой. Платные сертификаты мало кому нужны и могут понадобиться лишь в 2х случаях:
- Огромное количество поддоменов. Тут уместно взять Wildcard сертификат.
- Вы юрлицо и хотите чтобы рядом с замочком еще дополнительно отображалось название вашей компании. В этом случае вам понадобится EV сертификат.
В остальных случаях отлично подходит сертификат от Let's Encrypt.
Что-то не так с тестированием, скорее всего. Сложно представить возможное расположение сервера, где могло бы так произойти.
- У Пингдома есть особенность, иногда он сам меняет регион и проверяет не тем, который выбран. Можно не заметить.
- Общее суммарное время там могут сильно размывать асинхронные внешние элементы.
Как например, Яндекс и Гугл.Карты, счетчики, онлайн-консультанты и подобное.
- Иногда быстрые повторные тесты могут попадать в ДНС-кеши или в Keep-Alive от предыдущих, сильно ускоряясь.
- Проверять актуально на реально используемых аудиторией регионах.
Если сайт русскоязычный, то для сравнительных тестов не встречалось удобных вариантов, кроме ping-admin.ru и host-tracker.com.
Но Pingdom и по РФ\СНГ (из Стокгольма) частенько полезнее того же PageSpeed - для общей статистики и удобного анализа внутренних проблем сайта.
Если у вас виртуальный хостинг, то обычно настроить работу для бесплатного сертификата Let's Encrypt нет возможности.
И нужен либо хостинг, либо CDN c прямой поддержкой Let's Encrypt.
Для базовой настройки на своём сервере есть множество замечательных инструкций
