Чеклист обновления для интернет-магазинов, бронирования и корпоративных веб-сайтов

Вы планируете перезапуск? Поздравляем вас с тем, что вы нашли эту статью. Следующие пояснения могут стать для вас решающим вкладом в успех перезапуска и достижение великолепного результата. Потому что так бывает не всегда. Я - владелец агентства, и я расскажу вам, что именно позволит вам заставить таких, как я, делать исключительно хорошую работу и избегать типичных ошибок перезапуска. Но давайте начнем с самого начала.

Перезапуск веб-сайта - это редизайн и капитальный ремонт существующего сайта. При этом могут быть изменены дизайн, содержание и технология. Цель обновления сайта - улучшить его и адаптировать к современным требованиям.

Определенные внешние факторы в компаниях обеспечивают провозглашение цели "перезапуска": Вновь нанятый сотрудник приносит отличные идеи, новый босс приходит и хочет провести хорошую цифровую зачистку, у конкурентов появился новый сайт или продажи падают. Возможно, жене босса не нравится старый сайт или сайт недостаточно "зажигателен" для поколения Z. Возможно, вам это знакомо. Как и личное мнение, тот факт, что пришло время для нового сайта, не является причиной для перезапуска.

Однако есть несколько более веских причин, по которым компании или организации могут захотеть обновить свой сайт. Основными из них являются:

• Устаревший дизайн и/или ребрендинг: устаревший сайт может создать впечатление, что организация не идет в ногу со временем или перестала быть активной. Поэтому свежий, современный дизайн должен улучшить имидж. Даже если меняется имидж бренда или корпоративный стиль, часто требуется перезапуск сайта, чтобы отразить новый посыл бренда.
• Улучшение пользовательского опыта: если удобство пользования сайтом оставляет желать лучшего, это может привести к высокому проценту отказов. Перезапуск может улучшить пользовательский опыт и сделать сайт более удобным для навигации.
• Мобильная оптимизация: поскольку все больше людей заходят на сайты с помощью мобильных устройств, важно убедиться, что сайт хорошо работает на экранах разных размеров и устройств.
• Поисковая оптимизация (SEO): Устаревший сайт может иметь проблемы с SEO. Перезапуск дает возможность внести изменения, благоприятные для SEO, чтобы улучшить видимость в поисковых системах.
• Обновление контента: если информация, услуги или продукты компании меняются, необходимо обновить веб-сайт, чтобы отразить эти изменения.
• Улучшение безопасности: Старые веб-сайты часто более подвержены рискам безопасности. Перезапуск может способствовать повышению безопасности сайта и защите от кибератак.
• Обновление технологий: использование устаревших технологий может повлиять на производительность сайта. Перезапуск может дать возможность перейти на новейшие веб-технологии и платформы.
• Доступность: Улучшение доступности - одна из основных задач многих веб-сайтов, чтобы обеспечить их доступность для людей с ограниченными возможностями.
• Конкурентоспособность: Чтобы не отставать от конкурентов, важно иметь современный и мощный веб-сайт. Перезапуск может помочь сохранить или повысить конкурентоспособность.
• Аналитические улучшения: Внедрение более совершенных инструментов аналитики и сбор данных позволяют компаниям лучше понять и оптимизировать работу своего сайта.
• Соответствие юридическим требованиям: Законы и правила, касающиеся конфиденциальности, доступности и безопасности, регулярно меняются. Перезапуск может быть необходим для обеспечения соответствия сайта этим требованиям.

Эти причины могут возникать как по отдельности, так и в сочетании друг с другом и зависят от целей и потребностей компании. Перезапуск веб-сайта часто является стратегическим решением, направленным на улучшение присутствия в Интернете и достижение целей компании. Если рассматривать вышеперечисленные пункты по отдельности, становится ясно, что большинство причин можно реализовать в рамках небольших спринтов и не требовать масштабного обновления.

Поэтому давайте разберемся, что такое перезапуск и чем он не является: новый дизайн с существующей технической базой - это скорее подтяжка лица. Перезапуск является перезапуском только в том случае, если целью перезапуска является реальное изменение пользовательского опыта, функциональности и технической базы.

Перезапуск всегда должен быть обоснован фактами (например, технология зашла в тупик и больше не может обновляться), ключевыми цифрами, данными измерений и сравнений.

Это моя первая рекомендация на данный момент: эволюция перед революцией! Избегайте перезапуска как можно дольше и постарайтесь реализовать все пункты, которые были выдвинуты в пользу перезапуска, по отдельности или постепенно. Улучшите что-то одно, внедрите это, оцените, что получилось, адаптируйте снова или переходите к следующему пункту. Лучший пример - Amazon, который действительно вносит лишь минимальные изменения и улучшения и избегает крупных перезапусков на протяжении многих лет.

Перезапуск - это всегда большая угроза для вашей видимости в Google. Все сосредоточены на улучшениях, но мало кто осознает риск. Конечно, пользовательский интерфейс улучшается, положительный пользовательский опыт возрастает, и вы снова технически на высоте. Тем не менее, если успех вашего бизнеса зависит от сильной органической видимости , перезапуск - это последнее средство, и на него следует решаться только в том случае, если ваша боль достаточно велика из-за сочетания вышеупомянутых причин, которые уже невозможно устранить в рамках отдельных спринтов. Почему? Посмотрите, что произошло с онлайн-показателями после перезапуска этих четырех сайтов:

Тщательно спланируйте свой перезапуск и обеспечьте его успешную реализацию с помощью контрольного списка. Прежде всего, поставьте перед собой две цели: поддержание видимости в Интернете, с одной стороны, и поиск способов создания основы для повышения видимости в Интернете в рамках перезапуска, с другой. Эта статья призвана предоставить вам руководство по перезапуску, чтобы вы могли минимизировать риски во время перезапуска и добиться исключительно хорошего результата с потенциалом устойчивого, органического SEO-успеха.

Дорожная карта перезапуска

Планирование перезапуска сайта должно быть тщательным. Важно учесть следующие шаги:

• Анализ существующего сайта и ведение журнала: сначала необходимо проанализировать существующий сайт, чтобы выявить его сильные и слабые стороны.
• Определение целей: Необходимо четко определить цели обновления веб-сайта. К ним относятся, например, повышение коэффициента конверсии, увеличение числа посетителей или переход на новую CMS с улучшенной поддержкой и удобством работы с контентом.
• Разработка концепции: концепция обновления сайта должна быть разработана на основе анализа и целей, а также анализа конкурентов. Концепция должна включать следующие аспекты: Дизайн, контент, технологии и SEO/маркетинг.
• Реализация: Затем концепция реализуется. Сюда входит разработка дизайна, создание/адаптация контента и внедрение технических изменений.
• Тестирование: перед публикацией новый сайт должен быть тщательно протестирован, чтобы убедиться, что он работает без ошибок. Это также включает в себя определенный контрольный список.
• Публикация: После этого новый сайт публикуется. При этом его продолжают тестировать вживую, анализировать и адаптировать.

Определите цели и стратегию перезапуска

Точно определите цели перезапуска. Цели могут быть следующими (в дополнение к причинам, упомянутым выше)

• Улучшение пользовательского опыта
• Повышение ясности
• Расширение ассортимента контента
• Модернизация дизайна
• Увеличение оборота и размера корзины
• Переход на другую CMS с более простым обслуживанием контента и технической поддержкой
• Более легкая расширяемость и поддерживаемость в будущем.

Предложение: После первых стартовых встреч в команде как в компании - еще до начала обсуждений с агентствами-исполнителями - каждый участник проекта должен написать цели перезапуска на листе бумаги или в маске ввода в вашем коммуникационном инструменте (например, Slack). Когда все одновременно укажут свои цели, вы будете поражены тем, насколько сильно расходятся мнения, даже если цель уже обсуждалась устно на встречах. Поэтому важно излагать цели в письменном виде. Если вы точно знаете, каковы ваши цели, вы можете использовать прототип пользовательского интерфейса на ранней стадии, чтобы проверить, были ли они учтены концептуально.

Техническое задание вносит ясность в порядок перезапуска.

Чтобы подготовить предложение, агентству необходимо получить от заказчика исчерпывающую информацию о проекте. Обычно у компаний есть готовый документ Word или PDF, в котором проект изложен более или менее подробно. Затем проводятся анкетирование или семинары, с помощью которых агентства могут лучше подчеркнуть болевые точки заказчика, чтобы иметь возможность представить предложение. Для крупных проектов составляется спецификация. Чем подробнее, тем лучше.

Техническое задание - это документ, который играет важнейшую роль в обновлении сайта. В нем письменно фиксируются требования, цели и ожидания от обновления. Хорошо написанная спецификация помогает убедиться, что все участники процесса - будь то команда разработчиков, команда дизайнеров или клиент - имеют четкое представление о том, что должно быть достигнуто в ходе перезапуска. Она также является отправной точкой для хорошо просчитанного и обязательного предложения от реализующего агентства. Вот информация и элементы, которые обычно включаются в спецификацию для обновления веб-сайта:

• Цели и задачи: описание основных целей обновления, например, улучшение пользовательского опыта, повышение видимости в поисковых системах или смена CMS с обновлением дизайна.
• Объем проекта: четкое определение того, что входит и не входит в обновление. Это может включать количество страниц, интеграцию сторонних инструментов или пересмотр контента.
• Требования к дизайну: Информация о желаемом визуальном оформлении веб-сайта, включая макеты и соблюдение корпоративных рекомендаций по дизайну, касающихся цветов, шрифтов и изображений.
• Требования к функциональности: Описание желаемых функций и взаимодействий на сайте, таких как контактные формы, функции поиска, электронной коммерции и т. д.
• Технические требования: Спецификации технологий, которые будут использоваться во время перезапуска, например, выбор системы управления контентом (CMS) или реализация определенных функций. Сюда также входит использование современных форматов изображений и графики (WebP, AVIF, SVG).
• Ручное и автоматическое резервное копирование и редактирование контента.
• Требования к контенту: Четкие спецификации для пересмотра, обновления или создания нового контента, включая текст, изображения, видео и другие медиа. Работа с метаданными и структурированными данными.
• Требования к SEO: подробнее об этом в следующем разделе о контенте.
• График и основные этапы: график, определяющий планируемые даты начала и завершения перезапуска, а также важные этапы.
• Бюджет: информация о бюджете перезапуска, включая расходы на дизайн, разработку, хостинг и любые сторонние услуги.
• Обеспечение качества с помощью инструментов тестирования: Описание процедур тестирования и контроля качества, которые будут проводиться во время перезапуска, чтобы убедиться, что веб-сайт функционирует должным образом.
• Требования к обслуживанию и поддержке: Требования к текущему обслуживанию и поддержке веб-сайта после перезапуска.

Хорошо структурированный документ технического задания очень важен для того, чтобы избежать недоразумений, эффективно управлять проектом и гарантировать, что ожидания всех заинтересованных сторон будут удовлетворены. Он служит руководством и справочным документом для всей проектной команды и помогает обеспечить успех перезапуска сайта.

Когда мы планировали перезапуск TutKit.com с полной сменой фреймворка с CodIgniter на Laravel, наша спецификация требований составляла 220 страниц - не слишком заманчивая перспектива для агентства.

Примечание: в моей статье не будет подробно описана концепция, дизайн, функции и используемые технологии. Новый сайт, безусловно, будет красивым. Самая большая опасность при перезапуске - это ухудшение технического пользовательского опыта и качества страницы из-за отсутствия 301 редиректа и т. д., что впоследствии приведет к потере рейтинга и видимости. Чтобы предотвратить это, в следующем разделе мы сосредоточимся на обеспечении успеха проекта с точки зрения пользовательского опыта и SEO.

Определение SEO-требований к новому веб-сайту

Брифинг заказчика или даже более подробная спецификация уже регламентируют желаемые параметры дизайна, контента, функциональности и технологий и являются основой для составления агентством калькуляции.

Чтобы контрольный список перезапуска обеспечил успех проекта , отдельные переходы должны быть проанализированы с точки зрения SEO. Существуют особые SEO-требования , например, в связи с

• изменение структуры URL (карта редиректов!) и изменение путей ссылок
• меняющейся навигацией (важно учитывать внутреннюю перелинковку и иерархию ссылок)
• изменением технологий (CMS, JavaScript-фреймворк, сервер, ...)
• изменение контента (потенциальная потеря видимости для страниц, которые хорошо ранжируются).

Страницы хорошо ранжируются в Google благодаря релевантности их содержания , поэтому важно узнать, изменяется ли существующее содержание или объединяется, удаляется ли содержание и/или добавляется новое? Изменится ли структура контента категорий или страниц? Из этих моментов должны вытекать SEO-требования, которые должны быть включены в контрольный список перезапуска.

Будут ли перенесены метаданные старого контента и изменятся ли они? Как редактор поддерживает контент и связан ли контент страницы со структурированными данными?

Хранятся ли существующие или новые изображения в современных форматах для веб-сайтов (WebP/Avif) и уделяется ли внимание SEO-технологии изображений с URL-адресами в нижнем регистре букв, т. е. вместо 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Также следует позаботиться о том, чтобы файлы изображений передавались в Google через структурированные данные (ImageObject) и миниатюры <meta> , чтобы увеличить вероятность встраивания изображений в поисковые сниппеты и листинг в Google Images.

Еще один интересный вопрос в этом контексте - как можно улучшить пользовательские сигналы. Например, на контентные страницы можно встраивать видеоролики с изображениями, пояснительные и справочные видеоролики. Если пользователь, пришедший на целевую страницу из Google, нажмет на видео и посмотрит его, продолжительность пребывания увеличится (хороший пользовательский сигнал), а также повысится показатель возврата к SERP (хороший пользовательский сигнал).

Также следует проверить, как на страницах интегрированы разделы контента, отвечающие требованиям Google к полезному контенту и принципу E-E-A-T.

Для Google "полезный контент " - это контент, который является актуальным и полезным для пользователей. Он исчерпывающе и информативно отвечает на вопросы пользователей, предлагает решения проблем и обеспечивает дополнительную ценность, выходящую за рамки простого рекламного сообщения.

Вот несколько примеров полезного контента:

• Учебники и руководства: Этот контент помогает пользователям освоить новые задачи или решить существующие проблемы.
• Обзоры и сравнения: Этот контент помогает пользователям принять решение о выборе подходящего продукта или услуги.
• Новости и обновления: этот контент помогает пользователям быть в курсе текущих событий и тенденций.
• Инфографика и диаграммы: Этот контент помогает визуализировать сложные данные и информацию.
• Посты и статьи в блогах: Этот контент позволяет глубже понять определенную тему.

Google использует различные сигналы для распознавания полезного контента. К ним, в частности, относятся:

• Поведение пользователей: Google наблюдает за тем, как пользователи взаимодействуют с контентом, например, как долго они остаются на странице, как часто делятся им и как часто оценивают его.
• Сигналы качества: Google оценивает качество контента на основе таких факторов, как релевантность, полнота и актуальность.
• Отзывы пользователей: Google также учитывает отзывы пользователей, например, оценки и комментарии.
• Принимая во внимание эти сигналы, операторы сайтов могут повысить вероятность того, что их контент будет отнесен к категории полезных.

Принцип EEAT - это разработанная Google концепция оценки качества веб-сайтов и веб-контента. Он расшифровывается как Expertise, Experience, Authority and Trustworthiness, то есть экспертиза, опыт, авторитет и достоверность.

• Под экспертизой понимаются знания и опыт людей, создающих контент. Google оценивает экспертность на основе таких факторов, как образование, профессиональный опыт и награды.
• Опыт подтверждается, если контент был создан на основе определенного опыта, например, на основе фактического использования продукта, фактического посещения какого-либо места или описания человеком того, что он испытал.
• Авторитет относится к репутации веб-сайта или веб-контента. Google оценивает авторитетность на основе таких факторов, как обратные ссылки, активность в социальных сетях и отзывы пользователей.
• Достоверность - это надежность и авторитетность веб-сайта или веб-контента. Google оценивает надежность на основе таких факторов, как конфиденциальность, безопасность и прозрачность.

Какие SEO-требования предъявляются к существующим и новым функциям с точки зрения фронтенда и бэкенда? Вот несколько примеров:

• Ползучесть (релевантный контент должен быть виден и доступен для просмотра даже без JavaScript).
• Ясность цели сайта и четкость призыва к действию (желаемое поведение целевого клиента на страницах)
• Избегание дублирования контента, например, за счет автоматически созданных страниц категорий или дублирования страниц за счет статей-вариантов
• Обеспечение высокой скорости работы страницы за счет отсутствия большого количества файлов JavaScript и CSS и использования современных форматов изображений (WebP/AVIF).

Эти SEO-требования должны быть включены в брифинг проекта или в спецификацию, но также они должны быть включены в контроль качества проекта с помощью контрольного списка инструментов тестирования или в качестве сравнения АКТУАЛЬНОГО И ЦЕЛЕВОГО, а также в качестве критерия приемки услуг агентства. Подробнее об этом ниже.

Определите внутренних и внешних участников проекта

Определите участников проекта - здесь с точки зрения заказчика или владельца сайта:

• Кто отвечает за управление проектом и принятие окончательных решений?
• Кто отвечает за координацию и коммуникацию с агентством или клиентом?
• Кто отвечает за внутреннее управление проектом?
• Кто готовит контент и материалы для агентства внутри компании?
• Кто реализует дизайн пользовательского опыта?
• Кто осуществляет разработку?
• Кто и через какие промежутки времени отчитывается перед клиентом со стороны агентства?
• Кто отвечает за тестирование и обеспечение качества на стороне агентства/клиента?
• Привлекается ли внешний консультант (например, для SEO или по юридическим требованиям)?
• Кто выпускает задания? Кто утверждает задания в тикет-системе после обработки?
• Кто и когда должен быть проинформирован (сотрудники, клиенты, партнеры, менеджеры рекламных кампаний и т. д.)?

При выборе внешних менеджеров проектов важны четыре момента

1. Реализовывало ли агентство один или несколько проектов такого типа? Есть ли рекомендации? Существуют ли отзывы клиентов и можно ли провести обсуждение с клиентами агентства, что рекомендуется при крупных индивидуальных разработках?
   
2. Отвечают ли предлагаемые услуги и техническая реализация (CMS/система магазина/фреймворк) всем требованиям , связанным с перезапуском? Есть ли отдельные функции или требования, которые еще необходимо запрограммировать (в том числе с помощью плагинов или модулей)? Исключены ли из предложения или отложены на более поздний срок некоторые услуги, но которые имеют решающее значение для успеха проекта? Важно, чтобы не возникло никаких новых проблем , превышающих реальную причину перезапуска.
   
3. Подходит ли агентство-исполнитель или поставщик услуг для компании с точки зрения размера команды, регионального расположения и текучести кадров (это можно определить по обзорам Kununu)?
   
4. Возможен ли прямой контакт с командой разработчиков и исполнителей? Имеет смысл познакомиться с реальной проектной командой агентства. Специалисты по продажам, которые находятся в хорошем настроении и обещают голубое небо, получают работу и впоследствии перестают нести ответственность. По этой причине прямой контакт с командой реализаторов также должен быть согласован.

Четыре совета, как защитить себя в этом контексте

1. Как заказчик, я бы обратил пристальное внимание на технологию, которую использует агентство. Просто погуглите "CMS + недостатки" или "CMS + опыт", чтобы узнать, о чем говорится в предложении. Вы должны точно знать, во что ввязываетесь. Имеет смысл полагаться на решения с открытым исходным ко дом. Я понимаю, что это не всегда возможно. Лучше всего убедиться, что для используемой технологии существует как можно более широкое сообщество разработчиков , чтобы в итоге не получить собственное автономное решение, над которым может работать только ваше агентство, что в некотором смысле ставит вас впоследствии перед значительными ограничениями.
   
2. Также убедитесь, что вы получаете неограниченные права на использование и редактирование услуг агентства, чтобы у вас всегда было право на дальнейшее развитие сайта внутри компании или за ее пределами. Такой пункт должен быть прописан в договоре на выполнение работ и оказание услуг.
   
3. Если ваша компания более техническая и в вашей команде есть системные администраторы, разработчики программного обеспечения и т. п., имеет смысл установить GIT для управления версиями и JIRA (или аналогичный инструмент) для управления проектами или тикет-системой в отдельном аккаунте. Затем предоставьте агентству полные права доступа, и можно приступать к работе. Чем крупнее проект, тем грубее и болезненнее он может стать. Поэтому хорошо, если вы контролируете ключевые доступы и учетные записи. Однако я понимаю, что с чисто профессиональной точки зрения этой рекомендации могут следовать лишь немногие клиенты.
   
4. Иногда агентства предлагают хостинг для клиентов напрямую. Мы сами не сторонники этого, потому что, с одной стороны, это увеличивает зависимость в отношениях с клиентом, а с другой - мы говорим себе, что веб-хостеры лучше всего подходят для веб-хостинга, потому что они на нем специализируются. Мы уже настраивали и управляли серверами сами и потратили много человеческих и временных ресурсов. Мы снова вернулись назад. Теперь наши системы работают на облачных серверах одного из крупных хостеров в Германии, и мы счастливы. Выбирая хостинг, всегда убеждайтесь, что резервное копирование сервера уже включено в пакет и может быть импортировано всего несколькими щелчками мыши.

Определение периода времени и даты запуска

Перезапуск осуществляется в течение нескольких проектных спринтов. По опыту наших агентств, они могут быть следующими

• Фиксация текущего состояния (с помощью тестовых инструментов, а также в письменном виде с описанием того, что идет хорошо со стороны клиента и где необходимы улучшения)
• Исследовательская фаза с анализом конкурентов и поиском решений/вдохновения
• Концепция каркаса
• Создание дизайна пользовательского интерфейса
• Разработка фронтенда и бэкенда
• Миграция данных и импорт контента (автоматический/ручной)
• Структурная оптимизация и оптимизация контента (текст и изображения) и SEO-спринт

Спринты проекта пересекаются, так как в ходе проекта появляются новые участники.

Важно определить временные рамки для отдельных спринтов проекта и согласовать их с участниками.

Если проект более масштабный, создает ли агентство отдельный канал Slack для клиента, чтобы быстрее наладить коммуникацию?

Совет на этот счет: хорошо, если агентство работает с кликабельными прототипами на самом раннем этапе, то есть еще на этапе создания wireframe и тем более при представлении и тестировании дизайна пользовательского интерфейса. Это позволяет клиентам лучше понять, как работает сайт. Простые файлы JPG или PNG в качестве предложений по макетам уже неактуальны. Это должны быть кликабельные прототипы, созданные с помощью Sketch, Figma, Adobe XD или другого профессионального инструмента.

На этой ранней стадии изменения легко внедрить. Если же функции и разделы сайта уже разработаны, то изменения гораздо сложнее и могут привести к переговорным процессам, которые совершенно не нужны.

Здесь вы можете увидеть, как выглядит прототип дизайна мобильного пользовательского интерфейса, в обзоре которого показаны пути кликов:

Необходимо прояснить вопрос о том, когда возможно постоянное тестирование со стороны заказчика. Разработчики также должны тестировать свои локальные наработки после объединения в систему этапов. Звучит банально, но любой, кто работает с разработчиками, сразу поймет, о чем я. Затем сотрудник, отвечающий за обеспечение качества на стороне агентства, должен протестировать тикет или функцию. Только после этого билет передается заказчику для тестирования. Клиент никогда не должен чувствовать себя альфа-тестером , он должен найти систему, которая уже была проверена четырьмя глазами. Агентство - это альфа-тестер, а клиент - бета-тестер! Есть ли вообще доступ к тикет-системе агентства?

Также следует письменно определить, что отчеты агентства должны отправляться клиенту с определенной периодичностью. Например, каждую пятницу по электронной почте можно отправлять отчет о текущем статусе работы, необходимых циклах обратной связи или запросах на дополнительную работу. Это также совет из опыта работы нашего агентства: не стоит позволять клиенту уходить на выходные, не имея никакой определенности. Это только натолкнет их на глупые мысли. Лучше объяснить, что произошло и что будет на следующей неделе. Прозрачность помогает обеспечить хорошее отношение к проекту.

Также следует определить дату запуска. Согласно закону Паркинсона, работа расширяется, чтобы заполнить время, отведенное на ее выполнение. Другими словами, чем больше времени отведено на выполнение задачи, тем больше времени она займет, независимо от фактической сложности или объема работы. Планируемая дата завершения также включается в договор на выполнение работ. За несоблюдение сроков в договоре может быть предусмотрена неустойка. В качестве ориентира действуют договорные штрафы в размере 0,2 % от суммы заказа за каждый рабочий день просрочки и максимум 5 % от суммы заказа. Неустойка не обязательно должна быть востребована заказчиком, но дает вам право потребовать от агентства несколько специальных запросов в качестве компенсации.

Важно: Никаких запусков в пятницу. Даже в праздничные дни или в основное рабочее время компании. Мы вообще рекомендуем использовать ночные часы с воскресенья на понедельник для крупных перезапусков, особенно если меняется IP, чтобы в понедельник настройки DNS снова обновились у большинства провайдеров, что часто происходит поздно утром, если запись DNS была скорректирована в ночные часы. Таким образом, остается 4,5 рабочих дня для тестирования в реальном времени и исправления ошибок в случае их возникновения.

Регистрация текущего состояния вашего сайта

Перед началом работы необходимо зафиксировать текущее состояние. Фактическое состояние фиксирует результаты технических измерений параметров. Справа можно ввести целевые значения:

В этом списке вы найдете SEO-инструмент Seobility, который мы любим использовать для проверки факторов на странице, и для которого я также опубликовал обучающий курс по SEO. Существует множество аналогов, таких как Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog и т. д. SEO-инструмент в первую очередь предназначен для выявления и исправления типичных ошибок на странице. Seobility анализирует три основные области: технологию и мета, структуру и контент. В таком же виде вы найдете его и в других seo-инструментах. С одной стороны, важно, чтобы всегда проводилась полная проверка, то есть проверялись ВСЕ страницы, а не только главная, а с другой - чтобы вы вводили оценку или значение ошибки для текущего состояния и целевое значение, которое должно быть достигнуто после оптимизации. Для Seobility желательно значение 90 или выше. Вы также можете найти альтернативные инструменты для других целей. Решающим фактором является то, что один из них вообще используется для обеспечения выдающихся данных.

Это, например, наше текущее значение для качества страниц:

Сигналы пользователей могут быть статистически зафиксированы с помощью метрик Google Analytics 4, таких как показатель отказов, количество страниц/посетителей, продолжительность пребывания и т. д. Если Google Analytics или другой инструмент анализа используется в соответствии с требованиями к данным, эти данные также должны быть включены в протоколирование текущего состояния.

Также следует создать список обратных ссылок, который можно бесплатно сгенерировать, например, здесь: https://www.seobility.net/de/backlinkcheck/.

Кроме того, следует сохранить старый sitemap.xml , а также полную резервную копию сайта. Все релевантные страницы также следует перенести в виде списка в лист Google, который станет основой для карты перенаправления URL. Такой список в формате CSV можно легко экспортировать с помощью SEO-инструмента, например Seobility. Карта перенаправления URL включает все релевантные страницы и страницы, на которые ведут внешние обратные ссылки (см. список обратных ссылок) и которые необходимо перенаправить позже из-за изменения URL страницы. Исчезнувшие URL должны перенаправлять на новые URL, соответствующие старым. Важно предотвратить цепочки редиректов! Старые, еще существующие редиректы должны перенаправлять непосредственно на новый конечный URL. Вы также должны подумать о PDF-файлах и изображениях , на которые существуют ссылки, чтобы они также были правильно перенаправлены и не стали ссылкой 404.

Перенаправления настраиваются как 301 перенаправление на основе карты перенаправления URL в .htaccess, с помощью карт перенаправления через конфигурацию Vhost или решение на основе базы данных. Клиент должен быть в состоянии поддерживать их самостоятельно. Также необходимо убедиться, что перенаправления являются постоянными.

Также желательно подкрепить каждый тип страницы полностраничным скриншотом. С одной стороны, это резервная копия старого инвентаря на случай, если после запуска возникнут вопросы о том, не были ли перенесены типы контента и т. д.

На основе существующих страниц, функций и контента, а также результатов измерений можно определить, что уже работает хорошо, а что является областью, где есть потенциал для оптимизации, и что следует улучшить в ходе перезапуска.

Контрольный список: Перед перезапуском

Как только дизайн пользовательского интерфейса подтвержден и агентство находится в спринте разработки, становится актуальным следующий контрольный список, в котором в хронологическом порядке перечислены ключевые моменты вплоть до даты перезапуска:

1. Dev-среда с доступом для всех участников доступна для тестирования
2. Dev-среда работает на noindex
3. Настроен доступ тестовых инструментов к dev-среде (совместное использование IP-адресов или http-логин)
4. Конфигурация dev-среды максимально соответствует конфигурации живой системы
5. Структура страниц в dev-среде соответствует более поздней живой странице
6. Миграция старых данных завершена
7. Выполнена корректировка контента
8. Выполнено SEO изображений
9. Настроены 301 редиректы на основе карты редиректов URL
10. Выполнена проверка OnPage с помощью Seobility, ошибки исправлены, целевые значения достигнуты
11. Данные Open Graph действительны
12. Структурированные данные действительны
13. Выполнена проверка Pagespeed для всех типов страниц, целевые значения достигнуты
14. Политика контентных cookie работает
15. Заголовки безопасности настроены
16. Доступность задана, целевые значения достигнуты
17. Hreflang корректен (для многоязычных страниц)
18. Обновлены юридические тексты (положения и условия, юридическое уведомление, политика отмены, защита данных), достигнуто соответствие GDPR
19. Используемые CMS, фреймворки, плагины и модули обновлены до последней версии
20. Финальное функциональное тестирование кросс-браузерности и кросс-устройств не выявило ошибок
21. Объявлен окончательный статус и дата запуска
22. Создана полная резервная копия

Использованию структурированных данных (разметки схемы) - см. пункт 12 списка - сегодня уделяется слишком мало внимания. Ознакомьтесь с этой темой и прочитайте, что Google говорит о разметке структурированных данных в Google Search. Google будет придавать все большее значение достоверным данным в контексте SBU, т. е. результатов поиска, генерируемых искусственным интеллектом. Обновление полезного контента Google также требует, чтобы контент был гораздо более проверенным с помощью знаний, опыта, авторитета и доверия. Структурированные данные - часть решения, упрощающего эту проверку для Google. Используйте Schema Markup Validator после интеграции структурированных данных, но также проверьте свои страницы с помощью Structed Data Linter, который также рекомендован и связан Google в PageSpeed Insights. Это даст вам более подробную информацию об ошибках в коде, связанных с использованием структурированных данных.

Доступность впервые появляется в этой статье под пунктом 16. У доступности уже есть свой раздел в PageSpeed Insights, и зеленые цифры там желательны. В дополнение к PageSpeed Insights вам следует использовать https://www.accessibilitychecker.org и/или https://wave.webaim.org для проверки доступности страницы. Особенно если предстоит перезапуск, этот пункт следует учитывать в обязательном порядке, так как с 2025 года эта тема станет актуальной для веб-сайтов в связи с принятием Закона об усилении доступности. Используйте такой инструмент для проверки не только стартовой страницы, но и всех типов страниц - то же самое относится и к тестам PageSpeed!

Перезапуск часто влечет за собой корректировку и обновление правовых текстов. Важно подумать об этом на ранней стадии, чтобы при необходимости тексты были предоставлены специалистом-юристом или юридическими генераторами. Также следует продумать договоры на обработку заказов, если, например, используется новый веб-хост или меняется сервис рассылки.

Пункт 18, касающийся обновления CMS, используемых библиотек JavaScript, установленных модулей и плагинов, настолько же недооценен, насколько и важен. Перезапуск может занять несколько месяцев или больше. В случае с системой WordPress легко заметить, что многочисленные обновления могут быть доступны еще до даты перезапуска. Клиентам следует убедиться, что при запуске используются последние версии.

В случае смены внешних сервисов есть дополнительные задачи, которые также должны быть включены в контрольный список, например, при смене сервиса рассылки:

• Импорт контактных данных рассылки в новый сервис NL
• Подключение к сервису рассылки на сайте в форме регистрации
• Договор об АВ
• Создание новых шаблонов рассылки
• и так далее

В течение всего спринта разработки, естественно, происходит постоянное тестирование функций и т.д. Чтобы ничего не забыть, имеет смысл составить очень подробный контрольный список тестов. Агентству-исполнителю и заказчику недостаточно просто немного пощелкать мышкой. После перезапуска TutKit.com наш чек-лист для приемки тестов состоял из 1000 строк. И мы продолжаем работать в этом направлении до сих пор: после важных обновлений мы проверяем около 70 взаимодействий с помощью контрольного списка для Chrome, Safari и Android.

Контрольный список: День перезапуска и последующие дни

Наступил день перезапуска, и это не пятница и не праздничный день. Новый сайт запущен, настройки DNS настроены. Настало время еще раз все проверить и проанализировать. Проверьте следующее:

1. Проверьте robots.txt, чтобы убедиться, что роботы не заблокированы.
2. Живая среда работает в режиме index, follow.
3. Канонические теги установлены правильно
4. Проверьте исходный текст страницы на наличие абсолютных путей (пути ссылок тестового окружения на живой странице)
5. Работает ли перенаправление с http на https с/без www на целевую страницу на стартовой странице и подстраницах
6. Проверка перенаправления с помощью карты перенаправления URL, в том числе на наличие цепочек перенаправления
7. Проверка живой страницы с помощью Seobility на технологию и мета, структуру и контент ... особенно проверьте страницы noindex, которые выводятся через Seobility
8. Данные Open Graph действительны
9. Структурированные данные действительны
10. Проверка скорости страниц для всех типов страниц была проведена, целевые значения были достигнуты
11. Политика использования куки-файлов с инструментом согласия на использование куки-файлов работает как положено
12. Заголовки безопасности настроены
13. Доступность обеспечена
14. Проверка hreflang для многоязычного сайта(https://app.sistrix.com/de/hreflang-validator)
15. Окончательный кросс-браузерный и кросс-девайсный функциональный тест не выявил ошибок
16. Отправьте новый sitemap.xml в Google Search Console
17. Обновите новые целевые страницы для кампаний Google Ads
18. При определенных изменениях домена не забывайте о ссылках в социальных сетях, подписях электронной почты и т.д.

Мы используем Mailhog в нашей среде разработки для локального тестирования электронных писем. В таких случаях важно, чтобы правильные данные SMTP для получения писем были сохранены в реальной системе , чтобы письма отправлялись туда, куда должны.

Также важно убедиться, что в системе dev реализована "песочница" для поставщиков платежей, таких как PayPal, в то время как правильное соединение, конечно же, должно быть установлено в системе live.

В последующие дни особенно важно следить за работой Google Search Console. Конечно, самое интересное - это то, как меняется ваше ранжирование. Обратите особое внимание на неожиданные изменения и сообщения об ошибках:

1. Ползание: состояние хоста ... получение robots.txt, разрешение DNS, подключение к серверу
2. Статистика ползания... запросы, размер загрузки, среднее время отклика
3. Клики в SERP
4. Впечатления в SERP
5. Средний CTR в SERP
6. Средняя позиция в SERP
7. Прохождение основных показателей веб-страниц

Прежде всего, Google Search Console уведомляет вас об ошибках, таких как ошибки URL, ошибки href-long, индексация страниц с разбросом проиндексирован/не проиндексирован. Должна быть причина отсутствия индексации (редирект, noindex)...). Там же можно увидеть дублированный контент или другие проблемы. Если Search Console сообщает о проблемах со структурированными данными или Core Web Vitals, разберитесь в них. Только через живые данные вы узнаете, например, что у ваших страниц есть проблемы с показателями Core Web Vitals, несмотря на высокий PageSpeed, например, из-за ошибок CLS. Здесь вы можете наглядно увидеть скачки, которые возможны при внесении изменений на сайт:

Вы можете напрямую отобразить плохие URL-адреса или URL-адреса, которые необходимо оптимизировать. Возьмите URL-адрес и запустите с ним тест PageSpeed в PageSpeed Insights. После этого вы получите информацию о том, почему не соблюдаются основные показатели веб-страниц и что можно сделать для устранения ошибок. Для получения дополнительной информации нажмите на маленькую стрелку справа. Как правило, эти рекомендации могут быть выполнены только разработчиками. Однако важно, чтобы вы сами смогли выявить проблемы и затем устранить их с помощью своего агентства.

Также следует проанализировать данные, полученные с помощью инструментов аналитики, например Google Analytics 4, и следить за показателями, которые можно регистрировать на стороне системы, такими как бронирования, коэффициент конверсии, размер корзины, покупки/оборот в день, показатели регистрации в NL, запросы на контакты, загрузки определенного контента или просмотры видео.

Для проверки в последующие дни важна статистика посещений в Google Search Console. Их можно найти в настройках в меню слева. Активность ползания должна быть заметна сразу. Если нет, есть ли ошибки при переползании?

Статус хоста напрямую показывает ошибки, как это видно здесь после перезапуска, например, когда запросы на robots.txt не выполнялись, а соединение с сервером неоднократно прерывалось:

Интересно также посмотреть, что показывает статистика ползания. После перезапуска обычно наблюдается оживление запросов. Там же вы можете посмотреть, продолжают ли ползать 404 страницы. Если некоторые из них не вписываются в картину, обсудите их с разработчиками.

Вы можете определить, что ваш сервер, ваш PageSpeed и ваш код относительно хороши, если время отклика страницы составляет менее 400 мс. Чем ближе этот показатель к 1000 мс, тем целесообразнее оптимизировать PageSpeed, например, уменьшив количество запросов к базе данных и увеличив мощность сервера (например, увеличив вычислительную мощность, обновив серверное ПО до последней версии, перейдя на HTTP2 или HTTP3 (при использовании Nginx)).

В будущем бюджет на переползание отдельных веб-сайтов, вероятно, станет более ограниченным из-за увеличения количества контента (AI) на веб-сайтах, поэтому вы также должны стремиться к хорошему значению времени отклика страницы, чтобы боты переползали как можно больше на ваши страницы за отведенное время.

Контрольный список перезапуска для скачивания

Приведенные выше контрольные списки перезапуска также доступны в виде PDF-файлов, которые вы можете скачать здесь. Скачайте их и обеспечьте успех вашего проекта!

Исповедь владельца агентства

Требования к seo в чек-листе могут также включать подробные инструкции, такие как соблюдение структуры заголовков от H1 до H6 и так далее. К счастью, определение целевых значений в тестовых инструментах сокращает весь чек-лист перезапуска по содержанию, потому что достичь верхних значений тестовых инструментов, указанных в чек-листе, можно только при соблюдении чистоты кода, использовании современных технологий, соблюдении SEO-факторов на странице и т. д. В противном случае вам пришлось бы использовать новейшие веб-стандарты. В противном случае новейшие веб-стандарты, технические и SEO-требования должны быть детально прописаны в спецификациях, что клиенты даже технически не в состоянии сделать. Если агентствам необходимо получить высокие баллы в тестовых инструментах, у них не остается выбора, кроме как работать в соответствии с лучшими практиками - новый опыт и для агентств :-)

Пришло время для обязательств. Определение SEO-требований и процедура, напоминающая чек-лист, с гарантией и обязательным достижением целевых значений в различных тестовых инструментах представляет собой идеал, который редко встречается в реальности. Это зависит от

• бюджетных ограничений со стороны заказчика
• Интересы оптимизации прибыли на стороне агентства
• Ограничения, связанные с используемыми технологиями
• а также, к сожалению, от невежества и некомпетентности с обеих сторон.

Я вряд ли могу винить клиентов. В конце концов, они ищут профессиональной помощи, и почти каждое digital-агентство заявляет на своем сайте и в своих технических документах, что поисковая оптимизация является одной из его основных компетенций. Всегда есть ссылки, подтверждающие, что после перезапуска сайта его видимость в Интернете выросла в 3, 5 или 10 раз. То, что 100 посетителей в день теперь приходят с 10, - это 1000-процентный рост, но это ни в коем случае не успех. Многие успехи в поисковых системах означают, что конкуренты просто имеют гораздо более слабые цифровые позиции.

Агентства продолжают делать посредственную работу устаревшими методами, потому что до сих пор не используют современные инструменты для проверки качества , даже если в постах, рекомендациях, лучших практиках и т. д. говорится о том, что они обладают SEO-экспертизой. Возможно, такие агентства являются гигантами знаний, но тогда они также являются карликами исполнения. Звучит жестко, но это просто правило. На полном серьезе. Присмотритесь повнимательнее! Возьмите контрольный список, приведенный выше, и введите URL-адрес лучшего агентства из того региона, откуда вы родом, в вышеупомянутые инструменты. А затем возьмите последнюю ссылку на сайт, которую вы нашли у агентства, и повторите. Какие результаты вы увидите? Именно те результаты, которые вы можете ожидать от сотрудничества. Вы также можете проверить таким образом наши собственные ссылки, и вы поймете, что мы не всегда получаем высшие баллы, даже в проектах наших клиентов. Подобный рабочий процесс, ориентированный на проверку качества на основе данных , только развивается от проекта к проекту и утвердился в первую очередь благодаря нашей работе на TutKit.com.

Подобные обзоры можно проводить практически с любым агентством, потому что лишь немногие из них работают по-настоящему ориентированно на данные в обеспечении качества, потому что никто из них не остается в выигрыше, имея собственные проекты на рынке годами и вынужденный конкурировать с международными игроками в жесткой борьбе за видимость в Интернете , и потому что агентствам может быть практически все равно, удался проект или нет, лишь бы счет агентства был оплачен, а клиенты могли прославлять красивые (но посредственного качества) сайты в своих постах и наградах. Особая ирония заключается в том, что, согласно вышеупомянутым тестовым инструментам, именно SEO-агентства с собственными сайтами часто показывают худшие результаты, потому что у них в запасе есть только один метод, как у пони с одним фокусом... пакет контента для сайта, настроенный на ключевые слова клиента. Часто просто не хватает компетентных разработчиков для других технических требований.

Это также преимущество, если агентство находится в другом месте, и вы не встречаете клиента во время покупок в магазине DIY как ответственный сотрудник агентства, который просто обязан обеспечить падение видимости в двузначном процентном диапазоне после перезапуска. Но клиенты все равно почти никогда не проверяют это падение видимости , потому что, хотя у каждого есть баннер согласия на использование cookie, немногие действительно анализируют цифры и извлекают из них действия. В случае сомнений необходимо увеличить расходы на рекламу. К счастью, клиенты не понимают, что органическое ранжирование сегодня зависит в первую очередь от технических параметров, сигналов пользователей и (все еще) обратных ссылок из-за переизбытка сайтов с сопоставимым контентом. А благодаря текстовым инструментам ИИ сайты будут обновлять свой контент в беспрецедентном количестве и качестве, и вскоре мы сможем приветствовать в SERPs множество новых сайтов из-за рубежа на нашем национальном языке, потому что инструменты перевода ИИ будут все легче и легче переводить интернет-магазины, порталы, SAAS и другие сайты и атаковать цифровой внутренний рынок. Мы можем ожидать жесткой конкуренции. Все только начинается...

Заключение по чек-листу перезапуска веб-сайта на основе данных

Контрольный список, основанный на данных, - один из немногих эффективных способов заставить агентства хорошо выполнять свою работу. Целесообразно даже сделать достижение определенных значений в тестовых инструментах критерием приемки. В договоре должно быть оговорено, что счет на частичную сумму может быть выставлен только через четыре недели после перезапуска, если все важные данные доступны и подтверждают достижение максимальных значений (например, Core Web Vitals и подтвержденные сниппеты продукта в соответствии со схемой разметки в Search Console). С помощью этого рабочего процесса, описанного в данной статье, потеря видимости после перезапуска с серьезными контентными, структурными и техническими изменениями останется ограниченной, и вы создадите основу для того, чтобы Google вскоре повысил рейтинг вашего сайта или интернет-магазина.

Если эта статья показалась вам интересной, ознакомьтесь с другими нашими материалами: