1. 1.) Инвентаризация текущей страницы
2. 2.) Определение желаний и целей
3. 3.) Выбор соответствующего программного обеспечения
4. 4.) Обновление, обновление или полный перезапуск?
5. 5.) Создание макетов и каркасов
6. 6.) Настройка тестовой среды и разработки
7. 7.) Правильная стратегия SEO
8. 8.) Прямая связь с новым сайтом
9. 9.) Тестирование, тестирование, тестирование
10. 10.) Смотреть 404 и более ошибок сканирования
11. Мы с радостью ответим на все дальнейшие вопросы лично!

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

1.) Инвентаризация текущей страницы

Прежде всего, очень важно отслеживать текущие показатели, такие как трафик, коэффициент конверсии, продолжительность посещения и показатель отказов, поэтому мы сравниваем старую и новую страницы. Эти данные должны быть доступны как минимум в течение 2-3 месяцев, чтобы иметь значимые цифры. Бесплатные инструменты, такие как Google Analytics, Piwik или Google Search Console (ранее Инструменты для веб-мастеров) дают подсказки о текущем статусе.

2.) Определение желаний и целей

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

3.) Выбор соответствующего программного обеспечения

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

4.) Обновление, обновление или полный перезапуск?

Обновления вносят наименьшее количество изменений, так как обычно только версия системы управления контентом немного изменена. Более важно решить, стоит ли переходить на новую версию Major / LTS или полностью перезапускать. Для этого вам следует задать следующие вопросы:

Сколько страниц в дереве страниц? (полезный инструмент для этого: https://www.xml-sitemaps.com/ )
Должны ли существующие тексты и содержание быть сохранены или есть новая концепция?
Используются ли специальные расширения, которые могут привести к проблемам во время обновления?
Имеет ли смысл устанавливать новую HTML-инфраструктуру или она помогает адаптировать существующий код в зависимости от ситуации?

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

5.) Создание макетов и каркасов

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

6.) Настройка тестовой среды и разработки

Стабильная среда разработки является основой для успешного перезапуска. Важно отметить, что версии PHP, MySQL, соглашения с базами данных и наборы символов одинаковы, поэтому не возникает сложностей при последующем перемещении из-за устаревшего программного обеспечения или других языковых настроек. Кроме того, инструменты управления версиями, такие как «git» или подобные, помогают одновременно нескольким разработчикам работать над одним проектом, не перезаписывая файлы друг друга и не применяя более короткие сроки реализации проекта. Теперь вы можете начать с самой разработки и первых тестов сайта.

7.) Правильная стратегия SEO

Когда дело доходит до перезапуска, SEO может пройти долгий путь. Наиболее частым источником ошибок здесь являются несуществующие или неподходящие перенаправления 301, так называемые «постоянные перенаправления». Следующий сценарий: Google имеет URL-адрес www.my-domain.com/page-1 в индексе, который из-за переориентации, включая интернационализацию, теперь называется www.my-domain.com/en/page-1. Если вы не перенаправите этот URL, возникнет ошибка 404, и страница рано или поздно попадет в индекс поисковой системы. Таким образом, все позиции и ключевые слова теряются, и вы начинаете снова с нуля с рейтингом SEO.

Этот контрольный список SEO поможет вам с повторным запуском сайта:

Меняется ли структура URL? Если это так, я могу перехватить их по отдельности или с помощью регулярных выражений
Что происходит со страницами, которые могут больше не существовать? Где это содержимое осталось сейчас?
Определяются ли оптимально метаописания и теги заголовка на новой странице?
XML-файл Sitemap уже установлен?
Все ли фрагменты правильно реализованы для анализа посетителей? ( Google Analytics , Piwik , etracker или аналогичный)
Есть атрибуты title и alt, переопределенные / заданные в изображениях и ссылках?
Чрезвычайно важно в интернет-магазинах: есть ли у картинок значимые имена файлов, чтобы у них также была возможность ранжироваться при поиске картинок?

Обработка этого контрольного списка может занять очень много времени, но это определенно стоит того. В случае неопределенности в реализации, следует скорее колебаться и не рисковать, потому что однажды deindexierte сторона может в течение длительного времени означать выход из URL.

8.) Прямая связь с новым сайтом

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

9.) Тестирование, тестирование, тестирование

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

10.) Смотреть 404 и более ошибок сканирования

Как только стабильная функциональность веб-сервера и используемого программного обеспечения гарантируется, сканирование и ошибки 404 могут быть обнаружены и устранены как можно быстрее. Различные инструменты, такие как «ScreamingFrog SEO Spider» или «Google Search Console», помогают найти их. Если такая ошибка возникает, это не сломанная нога, но вы должны знать, что слишком большой промежуток времени для удаления деиндексации страницы с ней, чего следует избегать в любом случае. Период мониторинга должен составлять не менее 2–4 недель после включения в сеть, чтобы быть уверенным, что вы ничего не забыли во время повторного запуска.

Мы с радостью ответим на все дальнейшие вопросы лично!

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

Похожие

Комментарии