На сервере можно через потоковый редактор sed из консоли bash.
К примеру так:
find /var/www/site.test/ -type f -name '*.html' -exec sed -i 's|<h4>Категории</h4>|<h4>Kategorijas</h4>|g' {}\;
Таким образом можно делать и для многострочных блоков текста, но там надо поковыряться, по аналогии. Суть - команда sed меняет то что между вертикальными слешами одно на другое.
Вот тут есть статья о работе с такими html сайтами (восстановленными из вебархива), там побольше примеров. В том числе и добавление счетчиков, чистка кода, и т.д.
Да так-то автообновление для let's encrypt и прикручивать не надо, оно встроено в панельки управления - что в ispmanager, что в весту. И у шаредов обычно тоже выдается бесплатно с автообновлением.
Это не так. По-умолчанию ядро рубит по OOM процессы, использующие лишь более 50% доступной на сервере памяти. Это значит, что если ваш апач или mysql возьмет хотя бы 501 mb из 1 gb - ядро его килльнёт. При этом у вас может ещё оставаться на сервере свободными 200-300 мб от всей доступной. И вот это вот поведение никак не изменить на сервере OVZ. На KVM же решается всё изменением параметров ядра и всё дальше работает нормально. Я это всё не сам придумал, много раз сталкивался на практике с подобным и решал.
Да потому что даже 2 гб памяти - это лайтовый VPS, и на них часто бывает падение софта из-за этого. Да, будет показывать что половина памяти свободно, но софт валится по out of memory. Именно так это и происходит.
Пишу, потому что это один из основных аргументов против openvz. Ну да ладно, вам виднее. Тем более что уже определились, не вижу смысла что-то ещё доказывать.
Потому что он хочет взять vps с минимальной конфигой в 500 mb RAM, где часто бывают проблемы с падением софта якобы от нехватки памяти. Когда по факту памяти может быть достаточно, но ядро с дефолтными настройками будет рубить тот же mysql или apache по OOM. На VPS KVM с 500 mb RAM это можно решить докруткой параметров, на OVZ же никак. Если человек задаётся этим вопросом, то есть смысл озвучить все возможные "почему нет" сразу, раз уж он решил в этом разобраться. Ну а если это не аргумент - надо продолжать сидеть на шаредах.
Не стоит нигде и никогда. Только KVM, только SSD. Если возникает такой вопрос - то вам просто на шаред. Дешевле и проще.
Ибо во-первых риск оверселла, как тут уже писали. Ваш сайт может в пиковые часы тормозить непонятно почему. Потому что там у вас могут быть соседи, у которых нагрузка далеко не 3%. Во-вторых, на ovz нет доступа к управлению параметрами ядра, а это бывает нужно, особенно в случаях с минимальными конфигурациями, хотя бы для того чтобы выставить параметры overcommit_memory. Ну и в третьих, если возникает такой вопрос и нагрузка действительно минимальна - то вам вообще не нужен VPS. Юзайте нормальный шаред.
Нормально, это однозначно лучше, чем разбивать на два перехода. Смена домена это уже просадка, так нету смысла растягивать это "удовольствие" ещё и на https. И неважно как "отнесутся" к этому ПС, будет наверняка не хуже двухэтапного перехода.
Да никак это не отследить и не забанить. Много раз сталкивался у клиентов, что только не выдумывал - когда траф идёт с такого ботнета - никак его не блокнуть адекватно и гарантированно. Либо забанишь кучу нормальных юзеров, либо не забанишь весь рефспам.
Ну и обычно это сильно не мешает. По крайней мере сам яндекс уверяет, что никак подобный спам не влияет на позиции сайта, типа они отслеживают его и не налагают никакие санкции. Я тоже больше склоняюсь к тому, что если сайт нормальный, то не должны от такого проседать позициию
Ну в вашем же конфиге так и настроено. А как вы тут хотите тогда от двойного редиректа избавиться? Если бот сначала должен попасть на несуществующую страницу основного, а потом ещё и на главную основного. Либо вариант от Sitealert используйте - будет вам один редирект с каждой страницы зеркала сразу на главную основного. Либо показывайте по урлам зеркала на основном сайте 404, тоже будет один редирект, упирающийся в 404 на основном сайте.
Вам выдадут IP разумеется никем не занятый, но это не значит что он свежий и ранее никем не использовался. Таких адресов в мире уже практически не осталось, ибо их количество конечно. Никто там ничего не проверяет на плохую историю, чистый рандом.
Что касается влияния... Сеошники говорят, что может влиять ГЕО к которому относится IP. Типа если ваш сайт под СНГ, и ранее был он именно на российском айпи, а вы перекинете его на заокеанский IP, к примеру из США, то ПС могут отнестись негативно. Но это лишь один из каких-то сотых факторов, на практике обычно ничего страшного даже в этом нет. По крайней мере из многолетнего опыта работы с сайтами, серверами и всевозможными переносами. Разумеется адекватнее сохранить гео ваших новых IP поближе к юзеру, это логично как минимум с точки зрения доступа юзера к сайту. То есть сайт под сша лучше держать в сша, сайт под снг на российских или европейских IP. Тупо днс резолвится быстрее, выигрыш в десятки милисекунд, но сильно заморачиваться по этому поводу смысла нет.
