Продвижение сайтов на самописных CMS
13.08.2014 | Автор: Иван Андреев, Uplab (seo-специалист) 
Продвижение сайтов на самописных CMS или вообще без CMS — задача нетривиальная, особенно если самописка была предназначена для 5 страниц, а сайт вырос до 105.
Многие оптимизаторы периодически сталкиваются с такими случаями, и решают эту проблему все по-разному. Как правило, есть 2 варианта:
Перенести сайт на знакомую CMS. Вникнуть в сущность текущей системы или набора файлов, которые носят гордое название «сайт», и продолжить поддержку. У каждого пути есть свои нюансы. Перенос сайта с самописки — занятие неблагодарное и трудозатратное, но порой продолжать работать с текущей системой себе дороже.
С чем столкнется оптимизатор, решивший перенести сайт с рукописки? Для начала нужно получить входные данные, узнать насколько древняя рукописная CMS трудится на сервере.
Это может быть:
Набор html, php, asp-файлов с кучей папок, щедро приправленый документами Microsoft Word:
картинками всех калибров — jpeg, jpg, png, gif, bmp (!):
со всевозможными регистровыми вариациями написания имен файлов и их расширений, файлами стилей (css), ну и куда без javascript:
Весь контент хранится прямо там, где вы его найдете.
Если ваш набор более скромный — вам повезло больше. Не так давно мне пришлось работать именно с таким «супом». Поисковой оптимизацией здесь явно не заморачивались:
и т.д.
Отдельные php, asp-файлы, в которых уже есть «зародыш» удобства в виде подлючаемых «хэдеров», «футеров», меню. На этой эволюционной ступеньке возможно появление базы данных либо системы хранения контента в отдельных файлах. Уже лучше, но ещё не то.
Что-то похожее на CMS: индексный файл во главе всего, в него подключается библиотека функций, написанная в стиле процедурного или объектно-ориентированного программирования (ООП), что реже. Лишнего почти ничего нет. Контент в базе данных, все хорошо, но нет администраторской части, что доставляет некоторое неудобство в процесс внесения правок на сайте:
Полноценная рукописная CMS, работающая на принципе ООП. В игру включается еще один термин — MVC (Model-View-Controller, «модель-представление-контроллер»).
Если объяснить проще, MVC — это когда исполняемый программный код отделен от кода html-шаблона. На мой взгляд, MVC-модель удобнее на практике. Но если у вас php-код скрещен с кодом разметки html (привет любителям wordpress), тоже ничего страшного:
Гораздо хуже, когда он хранится в базе данных:
Итак, есть представление, насколько все «запущено». С чего начать? Url-адреса Сначала надо составить список url-адресов существующих страниц и сопоставить его со списком страниц, находящихся в индексе Google и Яндекс. Так можно понять, какие страницы необходимо перенести в обязательном порядке. Затем составить правила переадресации со старых страниц на новые.
Дизайн / верстка Нужно определить потребность в новом дизайне / верстке (что не одно и тоже). Порой у самописных сайтов структура DOM-дерева разнится от файла к файлу или имеет разные шаблоны вывода. Поэтому, создавая шаблон на новой CMS, нельзя быть уверенным, что все теги будут валидными или не появится лишний
Все сайты сделаны по канонам времени их создания. Сегодня эпоха html5. Xhtml тоже пока актуален. Старые сайты, как правило, целиком состоят из табличной верстки. Конечно, можно все оставить как есть, но рано или поздно придется прибегнуть к новым стандартам, а не «лепить костыли» с position: absolute;, к примеру, или магией javascript.
В новой верстке одни плюсы:
Уменьшение размеров файлов и оптимизация стилей (объединение правил, изменение их порядка). Как следствие, возрастает скорость загрузки. Простые конструкции не захламляют код страницы, упрощают и ускоряют последующие модификации. Работа с контентом При переносе контента важно обратить внимание на чистоту и валидность кода (параграфы, ссылки и пр.), потому что это может привести к нарушению структуры верстки. В коде контента может попадаться код стилей (как через вставку , так и через одноименный атрибут) или даже javascript.
В тех случаях, где требуется использовать уникальный стиль оформления, пропишите правила в общем css-файле, а нужному тегу присвойте соответствующий class или id. Что касается javacript, необходимо выяснить, применяется ли подобный код на других страницах. Если да, то следует вынести его в отдельный файл.
Готово? Самое время проверить, все ли верно Итак, все рутинные работы завершены, вы готовы произвести апдейт сайта на реальном сервере.
На данном этапе важно, чтобы правильно срослись старые адреса (например, не ЧПУ с ЧПУ). Сайт, имеющий позиции, не должен их потерять.
Стоит ещё раз проверить выдачу поисковых систем по текущему сайту и внести правки (по необходимости) в длинный список правил переадресаций, составленный ранее. Возможно, следует заняться внутренней оптимизацией ещё на тестовом сервере.
Как только будете уверены, что всё на своих местах, обновляйте сайт и продолжайте внутреннюю оптимизацию свеженастроенной CMS.
Недостатки самописных CMS Нужно разбираться в коде. Сложность внедрения новых элементов / компонентов. Оптимизация подчас превращается в отлов багов на сайте. Существуют CMS, которые и по сей день не удовлетворяют базовым требованиям SEO. К работе с контентом в каждой CMS свой подход. Все недостатки нивелируются, если вы или ваши специалисты умеют работать с CMS.
Самописка для SEO — есть ли смысл? Скромный кейс Когда мне передали очередной проект, ничто не предвещало, что с этим сайтом что-то не так. Сайт работает, позиции есть, вроде бы все хорошо. Да, дизайн устарел, есть недоделки, но в целом сильно не придерешься.
Сделал аудит и понял, что элементарная потребность добавить новую страницу или сгенерировать карту сайта влечет за собой очень много ненужных работ: обнови здесь, обнови там, залей сюда и т.д.
Вот что я увидел, когда зашел на FTP:
Здесь и ярлык на Microsoft Word, и архив версий страниц за различные даты и т.д.
По идее, было бы проще перенести на готовую CMS, но клиент не готов за неё платить.
Работать с сайтом как-то нужно, и чтобы работа не превращалась в рутину, решили написать собственный простой и seo-friendly движок сайта.
Главная концепция разработки — «ничего лишнего». В движок сайта я заложил несколько необходимых для SEO вещей:
Отдача адекватных http-заголовков, в том числе с учётом Expires, который влияет на скорость загрузки страниц. Генерация /sitemap.xml по запросу. Генерация древовидной html-карты сайта. Закрытие от индекса целого меню и пунктов меню в один клик. Генерация «хлебных крошек». Динамическая сборка информационных блоков (для перелинковки). Все метатеги хранятся бок о бок, поэтому обновлять их проще некуда. Движок написан с учетом MVC, поэтому любые правки в шаблоне не затрагивают исполняемый код. Это упрощает работу над сайтом и внедрение новых возможностей. Итоги обновления не заставили себя долго ждать, в ПС Яндекс сайт начал расти по мере обновления ссылок в индексе.
Заключение В вопросе замены рукописной CMS важно сохранять рациональное мышление. Существуют сайты, откровенно нуждающиеся в замене CMS, потому что поддержка текущего движка (если он вообще есть) будет нецелесообразной. А есть рукописные CMS, некоторые причуды которых можно потерпеть, изучая документацию или привлекая специалистов.
Если вы решите написать движок, сделайте так, чтобы любой разработчик смог в нём разобраться, не затрачивая много времени и не прилагая титанических усилий.
Полный текст статьи читайте на CMS Magazine
