Перелік для перезапуску онлайн-магазинів, бронювань та корпоративних веб-сайтів.

Перед вами стоїть перезапуск? Вітаю, що ви знайшли цю статтю. Наступні розмірки можуть стати важливим внеском для вас, щоб ваш перезапуск вийшов успішним і ви отримали чудовий результат. Бо це не завжди вдається. Я є власником агентства і розкрию вам саме те, що дозволить вам вимагати від людей, таких як я, дуже якісну роботу та уникальні помилки під час перезапуску. Але почнемо спочатку.

Перезапуск веб-сайту означає його переробку та оновлення існуючого веб-сайту. Під час цього можуть змінюватися як дизайн, так і контент, і технічні аспекти. Мета перезапуску веб-сайту полягає в поліпшенні веб-сайту та його адаптації до поточних вимог.

Певні зовнішні спонукальні фактори в компаніях приводять до вирішення мети "перезапуск": лише найнятий співробітник принесе чудові ідеї, новий керівник приходить і хоче також налаштувати порядок цифрово, конкуренти мають новий веб-сайт або знижується обсяг продажів. Можливо, дружині керівника не подобається старий сайт, або поколінню Z не досить "крутості" веб-сайта. Можливо, ви знайомі з цим. Також те, що час від часу потрібно новий веб-сайт, так само, як і особисті думки, не є причиною для перезапуску.

Однак існують кращі причини, чому компанії або організації хочуть провести перезапуск веб-сайту. Основні серед них:

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

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

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

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

Ось мій перший рекомендацію в цьому місці: Еволюція перед революцією! Уникайте перезапуску, поки це можливо, і намагайтеся реалізувати всі пункти, які були висунуті для перезапуску, почергово або інкрементально. Покращуйте одне, запускайте, аналізуйте, що відбувається, знову вносьте зміни або переходьте до наступної задачі. Найкращим прикладом є Amazon, які насправді мінімально змінюються та покращуються і вже багато років уникати великих змін під час перезапуску.

Перезапуск завжди є значною загрозою для вашої видимості в Google. Усі спостерігають за покращеннями, але мало хто за ризиком. Зрозуміло, що інтерфейс користувача стає краще, позитивний користувацький досвід зростає, технічно все знову актуальне. Тим не менш: якщо ваш успіх підприємства залежить від сильної органічної видимості, перезапуск - це останнє засіб та приймається тільки тоді, коли ваші болі великі в результаті поєднання вказаних вище причин, які не можна виправити в окремих спринтах. Чому? Подивіться тут, що відбулося після перезапусків цих чотирьох веб-сайтів у онлайн-видимості:

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

План реалізації реланчу

Планування реланчу веб-сайту повинно проводитися уважно. Важливо враховувати наступні кроки:

• Аналіз існуючого веб-сайту та протоколювання фактичного стану: спочатку слід проаналізувати існуючий веб-сайт, щоб виявити сильні та слабкі сторони.
• Визначення цілей: Цілі реланчу веб-сайту повинні бути чітко визначені. До них можуть входити, наприклад, покращення конверсії, збільшення відвідуваності або перехід на нову CMS з поліпшеним управлінням контентом і обслуговуванням.
• Розробка концепції: на основі аналізу та цілей, а також аналізу конкурентів, слід розробити концепцію реалізації реланчу веб-сайту. Концепція повинна включати наступні аспекти: дизайн, вміст, техніка та SEO/маркетинг.
• Впровадження: Потім доцільно втілюється концепція. До цього входить розробка дизайну, створення/адаптація вмісту та впровадження технічних змін.
• Тестування: Новий веб-сайт слід докладно протестувати перед публікацією, щоб забезпечити його бездоганну роботу. До цього входить також певний чек-лист.
• Публікація: Потім новий веб-сайт публікується. І продовжується пряме тестування, аналіз та налаштування.

Визначення цілей та стратегії реланчу

Визначте чітко, які цілі призначені для реланчу. Цілі можуть бути (окрім зазначених вище причин): 

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

Пропозиція: Після перших зустрічей у команді як компанія – ще до спілкування з агентствами виконавцями – кожен учасник проекту має внести цілі вашого реланчу на аркуш або у свій вхідний блокнот у вашому комунікаційному інструменті (наприклад, Slack). Якщо тоді всі одночасно покажуть свої вказані цілі, ви будете здивовані, наскільки відмінні є думки, незважаючи на те, що цілі вже обговорювалися словами під час зустрічей. Тому важливо також фіксувати цілі письмово. Якщо ви чітко знаєте свої цілі, ви можете вже на ранній стадії перевірити їх концепційне впровадження на UI-прототипі.

Технічне завдання надає ясність про завдання реланчу

Агентурі потрібна розгорнута проєктна документація від клієнта для розробки пропозиції. Компанії зазвичай мають готове документ Word або PDF, де більш або менше детально описано захід. Після цього відбуваються анкети або проводяться майстер-класи, щоб агентури краще виділити точки болю клієнта, щоб надати пропозицію. При великих проєктах створюється технічне завдання. Що воно детальніше, то краще. 

Технічний опис — це документ, який відіграє ключову роль у реланчі веб-сайту. Він призначений для того, щоб зафіксувати в письмовій формі вимоги, цілі та очікування від реланчу. Добре розроблене технічне завдання допомагає забезпечити, що всі зацікавлені – будь то команди розробки, дизайну або клієнта – мають чітке розуміння того, що має бути досягнуто під час реланчу. Це також є вихідним точком для ясного розрахунку та зобов'язується пропозицій із виконавської агентури. Ось інформація та елементи, які можуть зазвичай міститись в технічному завданні для реланчу веб-сайту:

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

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

Коли ми планували перезапуск TutKit.com з повним переходом від CadIgniter до Laravel, наше технічне завдання становило 220 сторінок - не дуже привабливий вигляд для агентства.

Примітка: В моєму матеріалі не буде детально розглядатися концепція, дизайн, функції та використовані технології. Новий веб-сайт, безумовно, буде привабливим. Найбільша загроза при перезапуску дійсно полягає в погіршанні технічного користувацького досвіду та якості OnPage через відсутність 301-перенаправлень тощо, що потім призводить до втрат рейтингу і видимості. Щоб цього уникнути, основна увага тут приділяється забезпеченню успіху проекту з точки зору користувацького досвіду та SEO.

Визначення SEO-вимог для нового веб-сайту

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

Для Чек-листа перезапуску з метою забезпечення успіху проекту потрібно розглянути окремі пункти з точки зору SEO. Особливі вимоги з SEO випливають, наприклад, з:

• змінюється структура URL (Map перенаправлень URL!) та шляхи посилань
• змінюється навігація (важливо для внутрішнього посилання та ієрархії посилань)
• змінюються технології (CMS, фреймворк JavaScript, сервер, …)
• змінюються вміст (можливі втрати видимості добре рейтингованих сторінок)

Сторінки мають хороший рейтинг у Google через їх суттєву значущість, тому важливо відповісти на питання, чи змінюються наявні вміст або об'єднуються, чи видаляються вміст або додаються нові? Чи змінюється вмістова структура категорій або сторінок? З цих пунктів повинні бути визначені вимоги з SEO, які повинні бути включені до Чек-листа перезапуску.

Чи будуть метадані старих вмістів також передані і змінюються? Як здійснюється догляд за контентом редактором та чи є вміст сторінок пов'язаний зі структурованими даними?

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

Також важливо враховувати, що файли зображень через структуровані дані (ЗображенняОб'єкт) та <мета>-Мініатюри передаються Google для збільшення ймовірності вбудовування зображення в ескізи пошуку та списку на Google Зображеннях.

Цікаво також з цього приводу розглянути покращення сигналів користувачів. Таким чином, на сторінках вмісту можуть бути вбудовані зображення-відео, пояснювальні та допоміжні відео. Якщо користувач, який приходить з Google на лендінг, клікає на відео та переглядає його, збільшується час перебування (гарний сигнал користувача), покращується також швидкість повернення на SERP (гарний сигнал користувача).

Також варто перевірити, як вмістові секції інтегруються на сторінках, які задовольняють вимоги Google для Корисного вмісту та для Принципу E-A-T.

Для Google "Корисний вміст" - це вміст, який є корисним та релевантним для користувачів. Він вичерпно та інформативно відповідає на запити користувачів, пропонує рішення для проблем та надає цінність, яка виходить за межі простих рекламних повідомлень.

Ось деякі приклади корисного вмісту:

• Навчальні посібники та інструкції: Цей вміст допомагає користувачам вивчати нові завдання або вирішувати існуючі проблеми.
• Огляди та порівняння: Цей вміст допомагає користувачам вибрати правильний продукт або послугу.
• Новини та оновлення: Цей вміст тримає користувачів в курсі подій та трендів.
• Інфографіка та діаграми: Цей вміст може допомогти візуалізувати складні дані та інформацію.
• Пости блогів та статті: Цей вміст надає більш глибокий вигляд на певну тему.

Google використовує різні сигнали для визнання корисного вмісту. До них входять, зокрема:

• Поведінка користувачів: Google спостерігає, як користувачі взаємодіють із вмістом, наприклад, як довго вони перебувають на сторінці, скільки разів її вони ділять та оцінюють.
• Сигнали якості: Google оцінює якість вмісту за такими факторами, як релевантність, повнота та актуальність.
• Зворотний зв'язок від користувачів: Google також враховує відгуки користувачів, наприклад, відгуки та коментарі.
• Враховуючи ці сигнали, власники веб-сайтів можуть збільшити свої шанси, що їх вміст буде визнаний як корисний.

Принцип EEAT - це концепція, розроблена Google, яка оцінює якість веб-сайтів та веб-контенту. Це означає Експертність, Досвід, Авторитет та Надійність, тобто Експертність, Досвід, Авторитет і Відповідальність.

• Експертність відноситься до знань та досвіду осіб, які створюють контент. Google оцінює експертність за такими факторами, як освіта, професійний досвід та нагороди.
• Досвід підтверджується, коли контент створено з певним досвідом, наприклад, на основі фактичного використання продукту, реального відвідування місця або описування подій особою?
• Авторитет вказує на репутацію веб-сайту або веб-контенту. Google оцінює авторитет за допомогою таких факторів, як беклінки, активність в соціальних мережах та відгуки користувачів.
• Надійність вказує на надійність та довіру веб-сайту або веб-контенту. Google оцінює надійність за такими факторами, як конфіденційність, безпека та прозорість.

Які SEO-вимоги є до існуючих та нових функцій щодо Frontend та Backend? Ось деякі приклади:  

• Прохідність (пов'язаний вміст має бути видимим та прохідним без JavaScript)
• Чіткість мети веб-сайту та чіткість щодо виклику до дії (потрібна поведінка цільового клієнта на сторінках)
• Уникання дублювання вмісту через, наприклад, автоматично створені сторінки категорій або подвійні сторінки з альтернативними товарами
• Забезпечення високої швидкості сторінки шляхом уникнення занадто багатьох файлів JavaScript та CSS, застосування сучасних форматів зображень (WebP/AVIF)

Ці SEO-вимоги повинні бути включені в технічне завдання проекту, а також у вимоги до якості проекту та додатково як критерій прийняття агентурної послуги. Більше про це нижче.

Визначення внутрішніх та зовнішніх учасників проекту

Визначте учасників проекту - тут з погляду клієнта або власника веб-сайту: 

• Хто несе відповідальність за управління проектом та прийняття остаточних рішень?
• Хто відповідає за координацію та комунікацію з агентством або з клієнтом?
• Хто відповідає за внутрішнє управління проектом?
• Хто підготовлює внутрішні вміст та матеріали для агентства?
• Хто втілює дизайн користувацького досвіду?
• Хто здійснює розробку?
• Хто звітує клієнту від агентства згідно з певною угодою?
• Хто відповідає за тестування та якість агентської роботи?
• Чи залучається зовнішній консультант (наприклад, для SEO чи юридичних вимог)?
• Хто затверджує завдання? Хто приймає завдання у системі квитків після виконання?
• Хто і коли повинен бути проінформований (співробітники, клієнти, партнери, управлявці рекламних кампаній тощо)?

При виборі зовнішніх учасників проекту важливі чотири пункти

1. Чи агентура уже реалізувала один або кілька проектів цього типу? Чи є рекомендації? Чи існують відгуки клієнтів та чи можливо провести справжній розмову з клієнтами агентури - що є рекомендованим для великих індивідуальних розробок?
   
2. Чи вже здійснено надання послуг та технічне виконання (CMS/система магазину/фреймворк), яке відповідає всім вимогам, пов'язаним з оновленням? Чи є індивідуальні функції або вимоги, які потрібно ще програмувати (навіть через плагін або модуль)? Чи існують конкретні послуги, які виключено або заплановано на пізніший час, але вони критично важливі для успіху проекту? Важливо, щоб не з'явилися нові проблеми, які більші, ніж саме обґрунтований привід для оновлення.
   
3. Чи підходить виконавство агентства або постачальника як за розміром команди, так і за регіональним розташуванням та (за оцінками через Kununu) ротацією співробітників також на довгострокове обслуговування компанії?
   
4. Чи можливий прямий контакт з командою дизайну та розробки? Розумно було б познайомитися з реальною командою проекту агентства. Співробітники з веселим настроєм та "небо по колу" обіцяючими професіоналами по продажам отримають завдання та потім не беруть на себе відповідальність. Тому важливо також домовитися про прямий контакт з виконавчими командами.

Чотири поради щодо власного захисту у цьому контексті

1. Як клієнт, я уважно стежу за використаною технологією агентства. Те, що вказано в пропозиції, можна просто згуглити за допомогою "CMS + недоліки" або "CMS + досвід". Тобто вам слід знати, в що ви точно вдаєтеся. Розумно віддати перевагу рішенням з відкритим кодом. Мені зрозуміло, що це не завжди можливо. Краще б керуватися можливістю мати якомога більшу спільноту розробників для використаної техніки, щоб ви не опинилися в кінцевому підсумку з рішенням, яке може обробляти тільки ваша агентура, що, яку в певному сенсі покладає вас в серйозні штанги в майбутньому.
   
2. Пам'ятайте також, що у вас є необмежені права на використання та редагування агентської роботи, щоб завжди бути здатним внутрішньо чи зовні постійно розвивати веб-сайт. Такий пункт повинен бути включений до угоди.
   
3. Якщо ваша компанія приділяє більше уваги технічним питанням та має системних адміністраторів, розробників програмного забезпечення тощо в своїй команді, раціонально встановити GIT для керування версіями та JIRA (або аналогічний інструмент) для управління проектами або системою квитків спочатку власноруч власному обліковому записі. Потім вам давати агентурі повний доступ, і роботи можуть початися. Чим більше проект, тим жорстким і важким він може бути. Тому добре, якщо ви керуєте ключовими доступами та обліковими записами. Але я розумію, що це рекомендація віддати з компетентного боку може бути виконана тільки найменшу кількість клієнтів.
   
4. Можливо, що агентства пропонують хостинг для клієнтів безпосередньо. Ми не є прихильниками цього, оскільки з одного боку це підвищує залежність у відносинах з клієнтом, а з іншого, ми вважаємо, що хостингові компанії найбільш підходять для хостингу веб-сайтів, оскільки вони спеціалізуються на цьому. Ми також вже встановили та керуємо власні сервери та витрачали значні людські та часові ресурси. Ми поверталися. Тепер наші системи працюють на хмарних серверах одного з великих хостинг-постачальників в Німеччині, і ми задоволені. У будь-якому випадку слід звернути увагу на те, щоб у пакеті вже входили резервні копії на серверному рівні, які можна легко відновити за допомогою кількох клацань.

Визначення терміну та дати запуску

Релінч буде виконано протягом кількох проектних спринтів. Згідно з нашим агентським досвідом, ці спринти можуть:

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

Ці спринти перекриваються, оскільки у процесі ​​роботи нові учасники проекту стають активними.

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

Чи створить агентство для клієнта, у разі якщо проект великий, власний канал Slack для швидшої комунікації?

Один порада на цьому етапі: добре, якщо агентство вже на дуже ранній стадії працює з клікабельними прототипами, тобто вже на етапі контуру, але ще більше на етапі демонстрації та перевірки дизайну інтерфейсу користувача. Так клієнти краще усвідомлюють, як буде виглядати веб-сайт. Прості файли JPG або PNG як пропозиція макету уже не є актуальними. Це мають бути клікабельні прототипи, які створюються за допомогою Sketch, Figma, Adobe XD або іншого професійного інструменту.

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

Тут видно, як виглядає такий прототип для мобільного дизайну користувацького інтерфейсу зі шляхами клацання в огляді:

Питання вирішується, з якого моменту можна проводити активні тести з боку клієнтів. Розробники повинні випробувати свою роботу на власних машинах після об'єднання в стежкову систему. Це може здаватися тривіальним, але кожен, хто працює з розробниками, зрозуміє мене відразу. Після цього той, хто відповідає за якість на боці агентства, повинен перевірити квиток або функцію. Лише після цього квиток буде дозволено для перевірки клієнтові. Клієнт повинен відчувати себе не як альфа-тестер, але вже мати систему, яка була протестована на своїх очах. Агентство є альфа-тестером, а клієнт — бета-тестер! Чи взагалі є доступ до системи квитків агентства?

Також слід письмово визначити, що щоденні звіти агентства клієнтові мають подаватися з певною частотою. Наприклад, кожної п'ятниці можна отримати звіт електронною поштою про поточний стан робіт, необхідні петлі зворотного зв’язку або запити на допомогу. Це також порада з нашого агентського досвіду: краще дати клієнту відпочити на вихідних з запевненням, що відбулося і що чекається на наступному тижні. Прозорість допоможе всім залишатися вдоволеними виконавцями та задоволеними своєю роботою.

Дата запуску також має бути визначена. Згідно із законом Паркінсона робота розтягується так, що вона займає уся вільну час на свої виконання. Іншими словами, чим більше часу виділено на виконання завдання, тим більше часу для цього відведено, незалежно від реальної складності чи зусиль. Процес завершення також повинен бути зазначений у договорі. Неналежне виконання строки може бути навіть узгоджено з громадянської відповідальностю в договорі. Як настанова, рекомендується, що штрафні санкції в розмірі 0,2% від суми замовлення за кожен робочий день затримки та максимально 5% від суми замовлення . Штраф можна не обов'язково вимагати від клієнта, але це дає вам можливість використовувати агентству кілька додаткових побажань як компенсацію.

Важливо: Не робіть запуск у п'ятницю. Не робіть його також між вихідними або в робочий час підприємства. Ми рекомендуємо фактично проводити запуск в нічні години з неділі на понеділок, особливо якщо змінюється IP, щоб на більшості постачальників DNS-налаштування були оновлені знову в понеділок, що часто відбувається вже до середини дня, якщо DNS-запис було оновлено у нічні години. Таким чином, практично залишиться 4,5 робочих дня для тестування на живому сайті та виправлення помилок, якщо вони з’являться.

Протоколування поточного стану вашого веб-сайту

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

Що?	Короткий опис	Інструмент тестування	Поточне (Актуальне значення)	Повинне (Цільове значення)
Техніка & Мета	Заголовок сторінки, Заголовки, Мета-дані, Альт-тексти, …	Seobility
Структура	Перенаправлення, пошкоджені посилання, Sitemaps, …	Seobility
Зміст	Відповідність ключових слів, Орфографічні помилки, недостатньо текстів, …	Seobility
SEO зображення	Говорят URL, сучасні веб формати (WebP / AVIF), <meta>-типові зображення	без
Дані OG зображення	Дані відкритого графу для соціальних мереж	Open Graph Checker
Структуровані дані (Схема маркера)	Схемний маркер / структуровані дані	Schema.org
PageSpeed Головна сторінка	PageSpeed для мобільних/робочих столів	PageSpeed Insights
PageSpeed Лендінг	PageSpeed для мобільних/робочих столів	PageSpeed Insights
PageSpeed Сторінка категорій	PageSpeed для мобільних/робочих столів	PageSpeed Insights
PageSpeed Сторінка продукту	PageSpeed для мобільних/робочих столів	PageSpeed Insights
PageSpeed Блог-сторінка	PageSpeed для мобільних/робочих столів	PageSpeed Insights
Доступність для різних типів сторінок	Забезпечити доступність для користувачів з обмеженими можливостями	Accessibility Checker або wave.webaim.org
Перевірка hreflang	Для багатомовних веб-сайтів	Hreflang Validator
Заголовки безпеки	Довіра і безпека	SecurityHeaders.com
Health-Check	Довіра і безпека	Security Audit (Astra)
Перевірка в браузері та на пристроях	Edge, Firefox У списку ви знайдете як інструмент для SEO популярний нами Seobility для перевірки OnPage-факторів, до якого я також опублікував Інформацію про SEO-тренування. Існує багато аналогів, таких як Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog та інші. Головна мета SEO-інструментів - ідентифікувати та усунути типові помилки OnPage. Тут йдеться про три основні області: Техніка та Мета, Структура та Контент, які Seobility оцінює. Подібні відомості доступні і в інших SEO-інструментах. Важливо, щоб здійснювалася завжди повна перевірка, тобто оброблюються ВСІ сторінки, а не лише головна сторінка, та, з іншого боку, щоб ви вводили показник або значення помилок для існуючого стану та для досягненняйого після оптимізації. В Seobility бажаним є показник 90 і вище. Також ви знайдете альтернативні інструменти для інших цілей. Рішенням є застосування хоча б одного, щоб гарантувати відмінні дані. Ось, наприклад, наш поточний відгук щодо якості OnPage: Сигнали користувачів можна статистично виміряти за допомогою показників з Google Analytics 4, таких як Відсоток відскоку, Сторінки/Відвідувачі, Тривалість перебування тощо. Якщо Google Analytics або будь-який інший аналітичний інструмент використовується відповідно до вимог, ці дані також повинні бути враховані в журналуванні існуючого стану.  Також варто створити список беклінків, який можна безкоштовно згенерувати, наприклад, тут: https://www.seobility.net/de/backlinkcheck/ Крім того, слід зберегти стару sitemap.xml, як і повне резервне копіювання сайту. Всі відповідні сторінки також повинні бути перенесені в список у Google Sheet, що є основою для карти перенаправлення URL. Такий CSV-список можна легко експортувати за допомогою інструменту SEO, такого як Seobility. В карті перенаправлення URL враховані всі відповідни сторінки та сторінки з зовнішніх беклінків (див. список беклінків), які пізніше потрібно буде перенаправити через зміну URL-сторінок. Сторінки, що втратили актуальність, повинні перенаправлятися на нові, відповідні сторінки з попередніх. Важливо уникати ланцюжків перенаправлень! Старі, існуючі перенаправлення повинні напряму вести на новий кінцевий URL. Також слід подбати про PDF-файли та зображення, на які є посилання, щоб вони також перенаправлялись правильно і не ставали посиланнями 404. Перенаправлення здійснюються як 301-перенаправлення на основі карти перенаправлення URL в .htaccess, через карти перенаправлень через Vhost-конфігурацію або через рішення на основі бази даних. Клієнту слід бути можливість самостійно піклуватися про це. Також обов'язково забезпечити довгостроковий характер перенаправлень. Також рекомендується захопити кожен тип сторінки за допомогою повносторінкового знімка. Це один із засобів загального збереження, якщо після запуску виникнуть запитання, чи контенти не були перенесені тощо. На основі існуючих сторінок, функцій та контенту та на підставі результатів вимірювань можна визначити, що вже працює добре, а що вимагає оптимізації, що має бути покращене через оновлення. Чек-лист: Перед ребрендінгом Після того, як дизайн інтерфейсу користувача підтверджено, агенція знаходиться в розробці, актуальним є такий чек-лист, який хронологічно вказує на основні пункти до дня перезапуску: Розробницьке середовище для всіх учасників тести доступне для тестування Розробницьке середовище запущено на noindex Доступність тести на розробницькому середовищі (розблокування IP або вхід через http) налаштована Налаштування розробницького середовища якнайбільше відповідає живій системі Структура сторінок на розробницькому середовищі відповідає майбутній живій сторінці Міграція даних старих даних завершена Внесені зміни вмісту Оптимізація SEO зображень проведена Створені 301-перенаправлення на основі карти перенаправлення URL  OnPage-перевірка з допомогою Seobility завершена, помилки усунені, досягнуто цілі Дані Open-Graph є правомірними Структуровані дані є правомірними Проведено перевірку Pagespeed для всіх типів сторінок, досягнуті цілі Політика відносно Cookie працює Встановлені заголовки безпеки Доступність забезпечена, досягнуті цілі Дійсні Hreflang (для багатомовних сторінок) Правова інформація (Умови використання, Імпринт, Політика відмови від підписки, Конфіденційність) оновлена, Доступність DSGVO забезпечена Оновлення CMS, Frameworks, використані плагіни та модулі на нову версію проведені Остаточний тест функцій між браузерами та пристроями показав відсутність помилок Остаточний стан та дата запуску відомі  Створене повне резервне копіювання Використання структурованих даних (схемно-розмітка) - див. пункти 12 списку - досі недостатньо уважно розглядається. Ознайомтеся із цією темою та прочитайте, що Google говорить про розмітку для структурованих даних у пошуку Google. Google все більше вагує на правдиві дані в рамках SGE, тобто результатів пошуку, створених за допомогою ШІ, а також у зв'язку з Оновленням Корисного Контенту від Google, яке вимагає великої перевіреності контенту через експертність, досвід, авторитет та довіреність. Структуровані дані - це частина рішення для спрощення цієї перевірки для Google. Після внесення структурованих даних скористайтеся провідником схемної розмітки, але також перевірте ваші сторінки за допомогою Linter структурованих даних, який також рекомендований і посилається в PageSpeed Insights від Google. За допомогою цього інструменту ви отримаєте інформацію про помилки коду у зв'язку з використанням структурованих даних. Застосування структурованих даних на веб-сайтах вже не є варіантом, а обов'язковістю. Google вимагає від вас правильний і надійний контент. Якщо ви не хочете опинитися поза увагою в результатах пошуку, які підтримуються штучним інтелектом, слід стурбуватися про Схему маркування на своїх сторінках! Unter Punkt 16 taucht jetzt zum ersten Mal Barrierefreiheit in diesem Artikel auf. Bereits bei den PageSpeed Insights hat Barrierefreiheit einen eigenen Bereich und grüne Zahlen sind dort wünschenswert. Der Test, ob eine Seite barrierefrei ist oder nicht, sollte dann neben PageSpeed Insights auch über https://www.accessibilitychecker.org und/oder https://wave.webaim.org erfolgen. Gerade wenn jetzt ein Relaunch ansteht, sollte dieser Punkt verpflichtend berücksichtigt werden, weil для веб-сайтів зі Законом про підвищення доступності від 2025 року це стане актуальною темою. Перевірте засобом не тільки домашню сторінку, але і кожен тип сторінки – це ж саме стосується тестів PageSpeed! Im Rahmen eines Relaunches ergeben sich oft auch Anpassungen und Aktualisierungen bei den Rechtstexten. Daran ist frühzeitig zu denken, dass die Texte ggf. über einen Fachanwalt oder über Rechts-Generatoren bereitgestellt werden. Ebenso ist an die Auftragsverarbeitungsverträge zu denken, falls beispielsweise ein neuer Webhoster genutzt wird oder sich der Newsletterdienst ändert.  Punkt 18 mit dem Update des CMS, der eingesetzten JavaScript-Bibliotheken, der installierten Module und Plugins ist ebenso unterschätzt wie wichtig. Ein Relaunch kann sich mehrere Monate und länger hinziehen. Beim WordPress-System ist es easy-peasy zu sehen, dass vielleicht vor dem Relaunchtag bereits zahlreiche Updates verfügbar sind. Da sollten sich Kunden absichern, dass die neuesten Versionen beim Going-Live verwendet werden.   Bei sich ändernden externen Diensten kommen weitere Aufgaben hinzu, die dann ebenso in der Checkliste benannt werden sollten, wie beispielsweise bei der Änderung des Newsletterdienstes:  Datenimport der Newsletter-Kontaktdaten zum neuen NL-Dienst Anbindung an den Newsletter-Dienst in der Website bei der Anmeldemaske AV-Vertrag Erstellung neuer Mailingtemplates und so weiter  Während des gesamten Entwicklungssprints finden natürlich fortwährende Tests der Funktionen etc. statt. Es ist sinnvoll, sich für die Tests auch eine äußerst detaillierte Checkliste zu machen, damit nichts vergessen wird. Es reicht nicht, sowohl als umsetzende Agentur als auch als Kunde nur mal ein bisschen rumzuklicken. Nach unserem Relaunch von TutKit.com hatte unsere Abnahme-Checkliste sicherlich 1.000 Zeilen. Und so halten wir es bis heute: nach wichtigen Major-Updates prüfen wir ca. 70 Interaktionen via Checkliste ab für Chrome, Safari und Android. Checkliste: Der Relaunch-Tag und die Folgetage Der Relaunch-Tag ist gekommen und es ist kein Freitag und auch kein Tag zwischen den Feiertagen. Die neue Website geht live, die DNS-Einstellungen sind angepasst. Jetzt heißt es, wieder von vorn alles zu prüfen und auszuwerten. Prüfe Folgendes ab:  robots.txt checken, dass robots nicht geblockt sind  Liveumgebung läuft auf index, follow.   Canonical-Tags sind richtig gesetzt Seitenquelltext auf absolute Pfade prüfen (Linkspfade der Testumgebung auf Live-Seite) Redirection von http auf https mit/ohne www zur Zielseite auf Startseite und Unterseiten funktioniert Weiterleitungen testen über die URL-Redirect-Map, ebenso auf Vorhandensein auf Weiterleitungsketten OnPage-Check der Live-Seite mit Seobility für Technik & Meta, Struktur und Inhalt … insbesondere die Noindex-Seiten checken, die über Seobility ausgegeben werden Open-Graph-Daten sind valide Strukturierte Daten sind valide Пункт 10 Cookie-Policy mit Consent-Cookie-Tool funktioniert, wie es soll Security Header sind eingerichtet Barrierefreiheit ist gegeben Hreflang checken bei mehrsprachigen Website checken (https://app.sistrix.com/de/hreflang-validator) Finaler browser- und deviceübergreifender Funktionstest ergab keine Fehler Neue sitemap.xml bei Google Search Console einreichen Neue Zielseiten bei den Google-Ads-Kampagnen aktualisieren Bei bestimmten Domainänderungen an die Links in den sozialen Medien, E-Mailsignaturen etc. denken Wir nutzen in unserer Dev-Umgebung Mailhog, um E-Mails lokal zu testen. In solchen Fällen ist es wichtig, dass die richtigen SMTP-Daten für den E-Mailempfang im Live-System hinterlegt sind, damit die E-Mails auch dahingehen, wohin sie sollen. Ebenso ist darauf zu achten, dass bei Zahlungsanbietern wie Paypal im Dev-System die Sandbox implementiert ist, während dann natürlich im Live-System die richtige Verbindung hergestellt werden muss. In den Folgetagen gilt es, vor allem die Google Search Console zu beobachten. Am interessanten ist natürlich, wie sich deine Rankings verändern. Lege deinen Fokus besonders auf unerwartete Veränderungen und Fehlermeldungen: Crawling: Host-Status … Отримання robots.txt, Розпізнавання DNS, Підключення до сервера Статистика краулінгу … Запити, Розмір завантаження, Середній час реакції Кліки в результатах ППС Імпресії в результатах ППС Середній CTR в результатах ППС Середня позиція в результатах ППС Стан ядерних веб-віталій  Перш за все в Google Search Console вказуються помилки, такі як, наприклад, помилка URL, помилка Href-Lang, індексація сторінок з покладенням індексовано/не індексовано. Якщо сторінка не індексована, це повинно мати підставу (перенаправлення, noindex)... Там ви також можете побачити дубльований контент або інші проблеми. Якщо Search Console повідомляє вам про проблеми зі структурованими даними або ядерними веб-віталіями, вивчіть це питання. Тільки завдяки живим даним ви, наприклад, дізнаєтеся, що сторінки від вас, незважаючи на високу швидкість завантаження, мають проблеми з ядерними веб-віталіями через, наприклад, помилки з CLS. Тут добре видно, які стрибки можливі при зміні на веб-сайті: Ви можете одразу переглянути погані або ті, що потребують оптимізації URL-адреси. Візьміть URL та протестуйте його за допомогою інструменту PageSpeed Insights. Там ви отримаєте вказівки, чому ядерні веб-віталії не виконуються та що ви можете зробити, щоб усунути помилки. Для отримання додаткової інформації розгорніть маленьку стрілку зверху вниз. Як правило, ці рекомендації можуть бути реалізовані тільки розробниками. Проте важливо, що ви здатні ідентифікувати проблеми, щоб потім вирішувати їх за допомогою вашого агентства. Також аналізуйте свої дані з аналітичних інструментів, наприклад, з Google Analytics 4. Також враховуйте ключові показники, які ви зможете системно виміряти, такі як бронювання, конверсійна ​​ставка, сума корзини, покупки/оборот на день, кількість підписок на розсилку, запити на контакт, завантаження певного контенту або перегляд відео.  Статистика краулінгу в Google Search Console є ключовою для перевірок у наступні дні. Ви знайдете її у налаштуваннях зліва в меню. Має бути видно більше активності краулінгу. Якщо цього немає, чи є помилки краулінгу? Статус хоста відразу показує вам помилки, наприклад, видно тут після редизайну, коли запити на краулінг robots.txt не вдалося та підключення до сервера частково відпадало: Цікаво, що показує статистика краулінгу. Зазвичай після редизайну спостерігається оживлення у запитах на краулінг. Також ви побачите, чи крауляться ще деякі сторінки з помилкою 404. Якщо деякі не вписуються в загальний контекст, обговоріть їх з розробниками. Ви побачите, наскільки добрі ваш сервер, PageSpeed і ваш код, якщо час реакції сторінки менше 400. Чим ближче він до 1000 мс, тим більш рекомендоване є оптимізація швидкості сторінки, наприклад, шляхом скорочення запитів до бази даних та посилення потужності сервера (наприклад, більше обчислювальної потужності, оновлення до останньої версії серверного програмного забезпечення, перехід на HTTP2 або HTTP3 (у Nginx)). У перспективі бюджет краулінгу для окремих веб-сайтів через зростання кількості (штучного інтелекту) контенту на веб-сайтах, ймовірно, буде обмеженим, тому також слід прагнути до хороших показників часу реакції сторінок, щоб боти могли крауліти якомога більше на вашому веб-сайті за відведений час. Перевірочний список для редизайну для завантаження Вбудовані вище перевірочні списки для редизайну також доступні у форматі PDF для завантаження. Завантажте їх і забезпечте успішність свого проєкту! Зізнання власника агентства Вимоги SEO у перевірочному списку також можуть включати детальні інструкції, такі як дотримання структури заголовків від H1 до H6 тощо. Встановлення цільових значень у тестових інструментах щасливо скорочує весь перелік завдань редизайну змістово, оскільки досягнення максимальних значень тестових інструментів, згаданих у перевірочному списку, можливе лише через дотримання чистого коду, використання сучасної технології, уваги до SEO-OnPage-Faktoren і т.д. В іншому разі довелося б дуже детально вказати нові веб-стандарти та технічні та вимоги SEO у технічному завданні, що клієнти взагалі не в змозі зробити за професійними причинами. Якщо агентства повинні досягати високих показників у тестових інструментах, їм не залишається нічого іншого, крім роботи за найкращими практиками – це також новий досвід для агентств :-) Час розкласти карти. Визначення вимог SEO разом з послідовністю дій та забезпеченням та виконанням цільових значень у різних тестових інструментах представляє собою ідеальне рішення, яке в реальності дуже рідко зустрічається. Це залежить від: обмеження бюджету клієнта інтереси агентства щодо оптимізації прибутку обмеження, пов'язані з використаними технологіями і, на жаль, також: незнання та недоуміння з обох сторін Я не можу докоряти клієнтам. Вони саме шукають професійну допомогу, і практично будь-яка цифрове агентство повідомляє на своєму веб-сайті та в білій книзі, що оптимізація для пошукових систем є однією з їх основних компетенцій. Завжди є посилання, що доводять, що після оновлення було здійснено збільшення онлайн-видимості в 3, 5 або 10 разів. Те, що з 10 відвідувачів на день тепер приходить 100, є збільшенням на 1000%, але це ще не є успіхом. Багато успіхів в пошукових системах вимагають того, щоб конкуренти були цифрово просто набагато слабкішими. Агентства продовжують виконувати середню роботу застарілими методами, оскільки вони до сьогоднішнього дня не застосовують сучасні інструменти для забезпечення якості, навіть якщо це звучить гучно в публікаціях, посиланнях, передових практик тощо, що навичка SEO є. Можливо, такі агентства - це знанійці, але також і виконавчі карлики. Це звучить гостро, але так і є. Просто по суті. Попробуйте ретельніше розглянути це! Виберіть найкраще агентство у вашому регіоні за відомостями, які маєте, та введіть його URL вищезазначені інструменти. А потім візьміть найновішу посилання на веб-сайт, яку ви знаходите від агентства, і повторіть це. Які результати ви побачите? Очікувані в результаті співпраці. Ви можете перевірити також наші власні рекомендації таким чином і виявите, що ми навіть у наших проектах клієнтів не завжди досягаємо найвищих результатів. Такий робочий процес з підходом до даних-орієнтованого забезпечення якості виріс у нас від проекту до проекту і особливо закріпився завдяки нашої роботі на TutKit.com.  Такі перевірки можна проводити практично з будь-яким агентством, бо дуже мало хто насправді працює за даними для забезпечення якості, бо ніхто не лишається на ринку з власними проектами протягом років і не змушений конкурувати у жорсткій боротьбі за онлайн-видимість з міжнародними гравцями, і агентствам майже байдуже, чи вдається проект чи ні, поки агентський рахунок оплачується та клієнти можуть святкувати красиві (але якісно середні) веб-сайти у своїх публікаціях та нагородах. Особливий парадокс полягає в тому, що після перевірки вищезазначених інструментів тестування часто саме SEO-агентства з власними веб-сайтами виходять найгірше, оскільки вони часто, як умільці, мають тільки один трюк у запасі ... пакет контенту, розширений за ключовими словами клієнта для веб-сайту. Для інших технічних вимог часто не вистачає компетентних розробників. Це також буде перевагою, якщо агентство буде знаходитися в іншому місці, і клієнт не зустрічається з відповідальним працівником агентства під час покупок у будмагазині, який відповідає за зниження видимості на двоцифровий відсоток після оновлення. Але це зниження видимості клієнти все одно майже не перевіряють, бо хоча всі мають банер згоди на файли cookie, але небагато людей дійсно аналізують цифри і витягують звідти дії. У разі сумнівів потрібно збільшити витрати на оголошення. Те, що сьогодні рейтинг в органічних результатів залежить від технічних параметрів, сигналів користувача і (завжди ще) від беклінків через велику кількість вмістово порівняно добре налаштованих веб-сайтів, клієнти на щастя, на щастя, ще не знають. І за допомогою текстових інструментів ШІ вміст і якість веб-сайтів підніматимуться на небачену кількість та якість, і ми скоро повітаємо багато нових веб-сайтів з-за кордону на національній мові в результатах пошуку, оскільки завдяки інструментам автоматичного перекладу ШІ все легше перекладати онлайн-магазини, портали, програми та інші веб-сайти і атакувати цифровий внутрішній ринок. Ми повинні готуватися до жорсткої конкуренції. Це тільки початок ... Висновок щодо даних-орієнтованої чек-листа перезапуску веб-сайту Такий дані-орієнтована чек-лист є одним із небагатьох ефективних способів примусити агентства дотримуватися якісної роботи. Рекомендується навіть зробити досягнення певних значень в тестових інструментах в якості критерію прийняття. Повинно бути узаконено угодою, що частина коштів може бути виставлена на оплату тільки через чотири тижні після оновлення, якщо всі важливі дані наявні і підтверджують досягнення найвищих значень (таких як основні показники якості веб-сторінок і підтверджені продуктові фрагменти за міткою схеми в консолі пошуку). За допомогою цього робочого процесу - як описано у цій статті - твій втрати видимості після оновлення зі значними змінами вмісту, структури та технічними змінами будуть обмежені, і ти створиш базис для того, щоб Google швидше ранжував ваш веб-сайт або інтернет-магазин. Якщо стаття була цікава для вас, радимо також перевірити інші матеріали від нас: 1101,908,1066,1086