Плануєте новий сайт? Як під час редизайну знизити ризик втрати позицій і заявок

Новий сайт у п’ятницю, у понеділок тиша

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

Графіка тут ні до чого. Винні три речі, які зробили разом із нею: адреси сторінок дістали нову структуру, тексти скоротили, щоб вони вмістилися в макет, а на бойовому сайті лишилася увімкнена заборона індексації з тестової версії.

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

Що насправді бачить пошукова система під час редизайну

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

Тоді йдеться вже не про новий одяг того самого сайту. Google бачить інші сторінки за іншими адресами й мусить наново зрозуміти, що компанія пропонує. Сторінка, яка рік збирала позиції за запитом «ведення бухгалтерії Брно», зникає, а замість неї виникає нова адреса, якої ніхто не знає і на яку ніщо не посилається.

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

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

Аж потім має сенс займатися анімаціями й відтінком кнопки.

Перш ніж замовляти новий сайт: складіть перелік

Спершу треба знати, що на нинішньому сайті працює. Не що вам подобається — що приводить людей і заявки. Це дві різні речі, і це зазвичай різні сторінки.

Із Search Console перед редизайном збережіть:

• сторінки з найбільшою кількістю кліків і показів,
• запити, за якими приходять люди,
• стан індексації та знайдені помилки,
• адреси, які Google знає й позначає як виключені,
• надіслані sitemap.

Експорт зробіть радше раніше, ніж пізніше: звіт про ефективність тримає дані за останні 16 місяців, і вікно зсувається. Коли за пів року ви шукатимете, як сторінка мала себе перед міграцією, їх уже може не бути. Як розібратися в Search Console, якщо ви відкриваєте її вперше, показує посібник із Search Console для власника компанії.

В аналітиці випишіть вхідні сторінки та зафіксовані конверсії — у малої компанії це зазвичай надіслані форми, кліки на телефон і на e-mail. І додайте також те, чого в аналітиці не видно: якщо люди телефонують після прочитання конкретної сторінки послуги, вона комерційно цінна, навіть якщо жодної конверсії їй не приписано.

Список адрес потім доповніть технічно — із системи керування вмістом, із sitemap.xml або краулером, наприклад Screaming Frog SEO Spider, який у безкоштовній версії обходить до 500 адрес. Самого лише обходу, однак, замало: він не виявить старих адрес, на які з сайту вже ніщо не веде, але на які досі посилається чужий сайт або які знає Google. Тому технічний список поєднують із даними із Search Console.

Результатом має бути одна таблиця: адреса, її показники й рішення, що з нею буде на новому сайті.

Що новий сайт мусить перебрати

Зберігати кожне речення чи кожну підсторінку не обов’язково. Але щодо всього, що приводить людей або допомагає отримати заявку, має існувати рішення — а не випадковість.

Підрядник має щодо кожної важливої сторінки вміти сказати, чому він її зберігає, змінює або прибирає. «На новому сайті для неї вже немає місця» — це не відповідь.

Адреси й перенаправлення: де ламається найчастіше

Найбезпечніше — лишити усталені адреси без змін. Якщо сторінка працює за адресою /ucetnictvi-pro-firmy/, немає причини робити з неї /sluzby/vedeni-ucetnictvi/ тільки тому, що так вийшла нова структура меню.

Іноді, втім, зміни не уникнути — типово при переході на іншу систему. WordPress із датами в адресах (/2021/03/nazva-statti/) переводять на чистіші /blog/nazva-statti/; Shopify нав’язує префікси /products/ і /collections/; при переході на сучасний фронтенд вирішують, чи адреси закінчуються слешем, чи ні. У всіх цих випадках діє те саме: стара адреса має повертати постійне перенаправлення 301 на конкретну нову сторінку.

Мапа перенаправлень має виглядати так — один рядок на одну стару адресу:

/stara-posluha/            → /nova-posluha/
/porady/stara-stattia/     → /blog/onovlena-stattia/
/zvyazhitsya-z-namy/       → /kontakty/

Чотири помилки, яких припускаються знову й знову:

1. Усе на головну сторінку. Відвідувач не знайде там того, заради чого клікнув, і піде. До того ж перенаправлення на головну не є заміною зниклої сторінки, це глухий кут.
2. Ланцюжок перенаправлень. Стара адреса → проміжна адреса → нова. Особливо коли міграція відбувається вдруге, а стару мапу лишають працювати поряд із новою. Перенаправлення має вести одразу на кінцеву ціль.
3. Канонічний тег замість перенаправлення. rel="canonical" — це підказка про дублікат, а не переїзд. Видалену сторінку він не розв’язує.
4. Старі адреси заборонені в robots.txt. Якщо Google не має права обійти стару адресу, він ніколи не дізнається, що вона веде деінде. Перенаправлення тоді ні до чого.

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

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

Тексти: найтихіша втрата з усього редизайну

Редизайн часто стає приводом замінити конкретні тексти трьома повітряними маркетинговими фразами. Сайт тоді має кращий вигляд і перестає відповідати на запитання, за якими вас люди й обирали.

На кожній сторінці послуги перевірте, чи нова версія досі пояснює:

• для кого призначена послуга і яку проблему вона розв’язує,
• що саме отримає клієнт,
• як відбувається співпраця,
• що впливає на ціну і в якому порядку вона перебуває,
• що має надати клієнт,
• який наступний крок.

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

Старіші статті розділіть на чотири стоси: перенести, оновити, об’єднати, видалити. Як вирішувати, розглядає матеріал Старі статті: оновити чи видалити?. Для редизайну важливе одне — жодна відвідувана сторінка не має зникнути без рішення і без перенаправлення.

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

Що перевірити на тестовій версії

Тестовий сайт захистіть паролем або обмеженням доступу за IP. Заборона в robots.txt — це не захист: адреси однаково потраплять назовні, наприклад через посилання в e-mailі або в аналітиці.

Перед запуском пройдіть щонайменше це:

• важливі старі адреси повертають правильний код і ведуть на правильну ціль,
• внутрішні посилання ведуть одразу на нові адреси, а не через перенаправлення,
• жодна важлива сторінка не має noindex,
• канонічні адреси вказують на бойовий домен, а не на тестовий,
• у вмісті не лишилося посилань і зображень із тестового середовища,
• sitemap.xml містить лише нові індексовані адреси,
• кожна сторінка має власний title, головний заголовок і опис,
• зображення завантажуються й мають змістовний альтернативний текст,
• мобільне меню, кнопки та форми працюють,
• форма справді доходить на корпоративний e-mail,
• вимірювання фіксує надсилання форми й клік на телефон,
• власна сторінка 404 пропонує шлях до послуг і до контактів.

Щодо форми не покладайтеся на напис «Надіслано». Перевірте доставку, відправника, тему, поведінку антиспаму й підтвердження клієнтові. Редизайн, після якого заявки падають у спам, має технічно бездоганний вигляд — і це найдорожча з можливих помилок. Що має містити форма і що з неї викинути, розбирає Форма заявки, яку люди справді надсилають.

Запуск і перші тижні

Запуск плануйте на час, коли доступні і розробник, і людина, яка вміє перевірити вміст, перенаправлення та вимірювання. П’ятниця по обіді перед відпусткою — поганий термін.

Одразу після публікації:

1. Зніміть захист і noindex із бойового сайту — і перевірте це у вихідному коді, а не в адмінці. У WordPress найчастіший винуватець — позначка Попросити пошукові системи не індексувати цей сайт у Налаштування → Відображення.
2. Перевірте robots.txt і sitemap.xml, а sitemap надішліть у Search Console.
3. Пройдіть найважливіші старі адреси та їхні перенаправлення.
4. Надішліть справжню тестову заявку й переконайтеся, що вона дійшла.
5. Перевірте, що конверсії вимірюються.
6. Пропустіть сайт через краулер і подивіться на коди 200, 301 і 404.

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

Далі стежте, найкраще в день запуску, за кілька днів після нього і потім регулярно: зростання кількості сторінок 404, адреси, нововиключені з індексації, падіння кліків у конкретних вхідних сторінок, кількість заявок і те, чи випадково не проіндексувався тестовий домен. Короткочасні коливання після міграції — це нормально. Але помітне падіння однієї конкретної сторінки не виправдовуйте тим, що «Google має звикнути» — спершу перевірте перенаправлення, індексованість, вміст і внутрішні посилання.

Скільки має коштувати SEO-нагляд над редизайном

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

Пропозиція має окремо зазначати: експорт і оцінку нинішніх сторінок, план перенесення контенту, мапу перенаправлень, перевірку тестового сайту, налаштування вимірювання та перевірку після запуску разом із виправленнями. Підозрілим є пункт «SEO до нового сайту» без переліку результатів — так само як і обіцянка, що редизайн збереже конкретні позиції. Ризиками керувати можна, місце у видачі не гарантує ніхто.

Тривожні сигнали, що міграцію ніхто не проконтролює:

• контентом планують зайнятися лише після затвердження графіки,
• ніхто не попросив доступу до Search Console,
• старі адреси «якось перенаправимо»,
• усі прибрані сторінки мають вести на головну,
• не призначено людину, відповідальну за перевірку після запуску,
• початковий сайт мають видалити без перевіреної резервної копії,
• успіх оцінюють лише за виглядом і швидкістю.

Якщо нагляд вам не по силах, а підрядник його не пропонує, вхідний аналіз складе перелік адрес і рішень ще до замовлення нового сайту, а після запуску перевірить, що саме перенеслося.

Коли відвідуваність після редизайну вже впала

Не починайте писати нові статті. Це найчастіша реакція й найдорожча помилка — у зламану дорогу сиплять новий контент, який іде тією самою дірою.

Спершу порівняйте старий і новий сайт. Відновіть список початкових адрес із sitemap, Search Console, аналітики або резервної копії, перевірте їхні коди й прив’яжіть їх до нових сторінок. Потім перевірте, що перенеслося з текстів, заголовків і внутрішніх посилань. Відсутні 301 додайте, sitemap надішліть ще раз — а коли Google має дістатися до перенаправлень швидше, може допомогти тимчасово лишити в Search Console і стару sitemap, щоб він знову обійшов старі адреси.

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

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