Я бы еще добавил, что если осталась предыдущая версия - сравнить их. Было бы понятно, вдруг там есть "левый" код. Тогда и остальные библиотеки, да и сайт в целом, стоило бы проверить.
Не совсем понятно. У вас есть сервер, на котором уже лежит почта. С него получают остальные. Вы хотите копировать на другой сервер, чтобы она так же лежала и с него была раздача. Что поменяется, за исключением того, что у вас добавится +1 еще один сервер, только локальный, который обслуживать будет еще гемморнее? Да и в чем геммор то заключается?
Фактически из схемы: сервер-клиенты, вы хотите сделать сервер-сервер-клиенты. Зачем?
Да, ошибся. В любом случае, я имел ввиду, что дата "блокировки" еще не наступила, по письму она "в будущем", потому блоки РСЯ еще наблюдаются на сайтах ГДЗ. Но да, спасибо, что поправили, неверно написал.
Если я верно прочел письмо от РСЯ у ТС, то там говорится, что домены будут заблокированы через месяц. То есть сейчас у всех еще РСЯ, а у кого отпадут - будет видно после 22 сентября.
И еще, я не думаю, что это из-за трафика. Скорее всего, они так "мягко" решили объяснить исключение ресурсов, на которых постоянно проблемы с авторскими правами. А чтобы не разбираться у кого что - просто всех сразу под одну гребенку. Тот же гугл адсенс часто блокирует такие сайты для показа рекламы, объясняя тем, что они не могут показывать рекламу на страницах со спорными авторскими правами. Так что, теперь у ГДЗ сайтов та еще проблема будет с монетизацией.
По большому счету обновиться на свежее малой кровью невозможно. Все плагины, шаблоны и прочее - уже другие. В том числе, возникнет вопрос совместимости версий самого php и его библиотек.
Можно сделать один из вариантов:
1) Законсервировать сайты, т.е. запретить все что можно, запретить изменение файлов веб сервером, запретить запись в папки для всех ролей, запретить изменение в бд, дать роль только на чтение и т.д. Это не всегда возможно сделать полностью и не подойдет, если на сайтах продолжают публиковаться материалы или комментарии, короче он не просто статик, а живой.
2) Если, опять же, сайты - статик и особо ничего не меняется - я такие консервы просто переношу на чистый html. Без БД, без php практически. Шансов такую статику взломать - ноль. Останется возможность правки каких-то мелочей и даже ручное подкидывание материалов. Опять же, не подходит, если сайт не просто бывший старый контентник, а живой и развивающийся. Либо, в планах с ним дальше работать плотно.
3) Собственно, очевидное - брать свежий движок, под него свежую тему и делать перенос данных. Тогда получите устойчивый свежий сайт без явных дыр, адаптивный шаблон и прочие современные плюшки. А раз сайты на выделенном сервере, то, по хорошему, стоит сразу и весь сервер переустановить, поставить свежую версию ПО, если старое используется: операционка, библиотеки и тд. Заказать параллельный сервер, развернуть свежее ПО, установить и сделать перенос, а затем, либо перекинуть DNS записи на новый, либо, иногда так возможно - перенести в пределах хостера IP на новый сервер, а старый, после проверки, убить.
Как-то так, ибо оставлять в старом виде такое себе удовольствие, постоянно бегать и проверять не ломанули ли снова )
Не, у меня много где наоборот. Там где давно забил и даже SSL не подключил - вверх, где подключен - вниз. Так что не показатель. Хотя, тут гадать бесполезно, никакой логики.
Какой-то жутко странный ап.
Там где сайтами не занимаюсь давно и они уже почти в утиль пошли, ни трафика ни интереса - ИКС вверх до 33%.
Те сайты, которые наоборот, вроде как более популярны и интересны посетителям и все окей - минус почти до 67%.
И лишь один сайт худо бедно из всех подрос правильно, но всего на 10%.
Не удивлюсь, если перекрутили и откатят. А иначе прям аж задуматься будет над чем )---------- Добавлено 30.07.2019 в 20:32 ----------
Даже с учетом этого - теперь ИКС вообще не бьет в сравнении с реальным положением дел на сайтах. Где интерес пользователей выше - икс значительно ниже, где интереса вообще нет и сайт уже умирает - ИКС вверх. Моя не понимать логику.
Выше верно указали, удалить необходимо только кэш. Он содержит настройки редиректов, в том числе. Куки и данные файлов удалять при этом не требуется. Сам этим периодически пользуюсь.
Только в моей последней версии меню выглядит чуть иначе, ну и перегружать браузер не требуется, достаточно перегрузить страницу где был редирект. Полагаю, что это уже чисто вопрос установленной версии.
Добавлю отдельной строкой. Бывают такие изображения, когда они сами по себе осмысленны и их можно использовать отдельно от контента. Ну, для примера, всякие разные цитаты на изображениях, инструкции или еще что-то схожее. Такие изображения имеет смысл отдавать под основным доменом. Нередки случаи, когда пользователи делятся ссылками непосредственно на картинку, что учитывается в обратных ссылках. Не знаю насколько этот вес велик, но при большом распространении изображений - получается неплохой их обратный приток.
С тех пор как ПС жестко урезали трафик с картинок - это дело вообще не имеет большого значения. Да и когда не был урезан трафик - я держал картинки на отдельных серверах и все было отлично.
По факту я работаю по такой схеме:
1) Отдельный сервер с изображениями
2) В большинстве случаев это поддомен основного домена, типа img.maindomain
3) cname я не использую, поскольку для хранилища использую обычные виртуалки и настраиваю прямую запись, но можно и через cname, при необходимости
4) Ничего обратного не настраиваю, незачем. На картиночном нет ни индекс страницы, ни каких-либо еще. Ничего никуда не редиректит.
5) SSL на сервере изображений не суть важен, но если вы хотите зеленый замочек в строке браузера на своем сайте вместо желтого предупреждения - да, ssl нужно ставить. Я устанавливаю, это 10 минут дела.
6) Нужен ли отдельный SSL сертификат - зависит от того, какой у вас ssl-сертификат сгенерирован, если он распространяется на все поддомены - можно и нужно использовать его же в настройке, если не включает - сгенерировать для поддомена. У меня отдельно сгенерированные.
Разницы влияния от того где у меня живут картинки и прочий медиа-контент не замечаю. Чисто вопрос удобства.
