А на чем сделаны сайты? Если что-то из известных CMS вроде WP - то там это легко делается через замену домена в паре таблиц или через специальную функцию.
Ну а вообще, самый топорный и работающий метод - массовая замена рекурсивно site.com на old.site.com по файлам и в дампе базы. Дамп снимается, делается замена, заливается обратно. А, ну и редиректы для старых страниц - это отдельная история. Хотя, логично было бы перенести эти страницы в новый сайт.
Микроразметка
Посмотрите исходник таких страниц, где это подтягивается, в нем есть meta property. Вот они все это описывают.
Эта ошибка говорит о том, что ваш браузер не может найти IP сервера, при обращении к домену. Такое бывает когда истёк домен, а не сам сервер. Если вы знаете IP сервера, попробуйте набрать его в браузере. Если сайт откроется, то скорей всего дело именно в этом.
Ну и кстати, возможно просто именно ваш dns-кэш не обновился на самом компьютере или в локальной сети. Но без адреса сайта этого не узнать. Вы пробовали открыть сайт из других мест - из дома, скинуть другу и попросить его зайти? или через сделать проверку через сервисы.
А админ ваш - параноик :)
Это может быть, конечно. Я использую без панелей или vesta.
Про "не имеет значения" я говорил в том смысле, что вся моя аргументация может не иметь для ТС значения, поскольку он администрировать собирается через панельку. Ибо с той стороны - что центос, что deb - разницы нету - он же только isp видит и использует. Ну и топик тогда весь не более чем холивар, лясы поточить) какая разница что ставить, если ISP всё равно в итоге) Действительно, втыкайте сентос и дело с концом.
Нужно настраивать вебсервер таким образом, чтобы он отпинывал или не отвечал на запросы, на которые не положено отвечать.
Например, для nginx, нужно задать дефолтную конфигурацию такого вида:
server { server_name _; listen *:80 default_server deferred; return 444; }
Тогда ваш вебсервер будет отвечать только на такие имена и адреса, которые явно указаны в конфигурации nginx и для которых описана директива server_name site.ru www.site.ru
На любые подставные имена, кои не указаны в конфиге, сервер будет кидать empty_response.
А если сайтов на сервере много? Тогда можно создать мультисайтовый конфиг для nginx.
Ubuntu 14.04 LTS server 64-bit - лучший вариант. Особенно если вчитаться в стартовый пост.
Эта ОС про стабильность+поддерживаемость+удобно управлять.
Почему?
1. LTS = несколько обкаттанных и оттестированных сборок. Это стабильность уровня Debian, но...
2. Ubuntu легче конфигурится, ибо там всё нужное включено по умолчанию, все что доустанавливается - запускается и добавляется в автозапуск - автоматически, дефолтные конфиги более удобные. Особенно если это сравнивать с Centos, в коем по дефолту настроен только файрволл, который наоборот новичку не нужен и может лишь добавить проблем. В центосе весь софт надо запускать и тщательно конфигурить, включать автозапуск. В centos нужно почти всегда заморачиваться с добавлением репозиториев, в отличие от убунты. В дебе кстати, тоже. Это вот про удобство и дружелюбность. А если решите юзать centos 7 - так это вообще совершенно новая система, с которой придется любой чих гуглить.
3. Убунту - это более новый софт. А самый новейший устанавливается в 1 запрос в гугл + 3 команды - add-apt-repository ...; apt-get update; apt-get install ...; В отличие от дебианов, где немного с этим сложнее.
4. Ubuntu - это быстрое решение любой проблемы и задачи с 2-3х запросов в гугл.
Впрочем, если вы собираетесь админить через панель управления - для вас это ведь не имеет особого значения.
Что касается конфигурации VPS - такой выдержит около 20к суточного трафика, если запускать nginx+php-fpm и стандартный wp. Нормально настроенный, разумеется. На апаче около 5к, но с натяжкой.
Я думаю нужно попробовать. Я плохо представляю себе эту систему с биллингом, никогда не работал таким образом. Давайте обсудим это в скайпе, ответил вам в ЛС.
Оптимизация под Google стоит 1000 руб - как типовая услуга. Но нужно понимать, что я не оптимизирую сам js и css, не занимаюсь кодингом и версткой. Поэтому при полной оптимизации могут понадобиться услуги соответственно кодера. Сжатие+кэширование+оптимизация изображений - это могу настроить.
Вообще, Den73 прав, shutdown на мастер-хосте должно быть достаточно, он аккуратно может потушить виртуалки. Что до вашего случая из опыта - скорей сего там на виртуалке просто была проблема с неконсистентностью файловой системы с прошлых загрузок-перезагрузок.
В таком случае проверка и восстановление фс запустится как ни крути - даже если пойти ещё дальше и ручками все сервисы повыключать, на виртуалке > shutdown ей > сервисы на хосте и shutdown ему.
Это если есть "глючащие" виртуалки, с непонятными ошибками в логах БД или системы - есть смысл стопать их именно так, иначе есть риск получить битые mysql/postgresql после запуска и fsck файловых систем. С остальными службами и файлами вряд ли что случится, а вот с БД могут быть неприятные оказии.
Если же есть уверенность что все тип-топ, работает, не глючит и err-логи девственно чисты - то shutdown -h 0 на основном хосте и дело в шляпе! :)
Что-то уже час прошел, как всё списано, квитанция об оплате лежит в мыле, но доступа к коммерческому разделу так и нет.
В комментах кода страницы достаточно будет. Ещё интересный вариант - в роботс коммент добавить.
Тот, кого заинтересует разработка подобного движка/сайта, возможно будет смотреть код страницы. По крайней мере сеошники/вебмастера. Если заказчик не хочет ставить на вас ссылки - пытаться лепить их туда по меньшей мере неадекватно. Если заказчики не хотят ставить на меня ссылку, я бы задумался о качестве своих услуг.
