Можливі помилки при просуванні. Глава з нової книги

1. Соціальні мережі і шлях клієнта
2. Зміна структури сайту
3. Зміна адресації сторінок
4. редіректи
5. Таблиця відповідності адрес
6. Використання JS і AJAX в новому дизайні
7. Занадто пізніше оповіщення про редизайн
8. зміна домену
9. зміна протоколу
10. Зміна підрядника по SEO
11. Висновки
12. Корисні посилання

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

Але після проведення необхідних робіт по оптимізації і просуванню сайту, з'являється нове завдання - зберегти досягнутий результат протягом усього життя проекту. Щоб розв'язати цю проблему, потрібно розуміти, які складнощі і помилки можуть виникати в процесі розвитку і існування сайту. Саме їх ми і розберемо.

Книга з'явиться у продажу до кінця року.

Соціальні мережі і шлях клієнта

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

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

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

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

Але за всіма цими позитивними змінами може ховатися невидима на перший погляд біда.

Уявімо собі, що корпоративний сайт або магазин був створений 3-4 роки тому і прожив цей час в старому дизайні, а потім компанія вирішила оновити сайт.

Розробник - не важливо, чи буде це штатний співробітник або компанія-підрядник - з ймовірністю 99,9% заявить про необхідність змінити систему управління сайтом (content management system або CMS).

Як ми вже говорили, CMS - це «движок сайту», система для створення, управління і показу відвідувачам вмісту сайту. Іншими словами, це ядро ​​сайту, що складається з набору скриптів, інтерфейсу адміністративної панелі, бази даних і т.д. Тому, рекомендуючи змінити CMS, розробник може бути в принципі прав, оскільки старий движок сайту може не відповідати сучасним вимогам веб-розробки і не дозволить реалізувати всі ті зміни, які заплановані в ході оновлення сайту.

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

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

Давайте трохи докладніше зупинимося на цих ризиках.

Зміна структури сайту

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

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

Після зміни рівнів вкладеності сторінки, які в структурі були на другому рівні вкладеності, можуть виявитися на десятому рівні або навпаки. Це обов'язково вплине на на ранжування сторінок в пошуку.

Якщо рівень вкладеності сторінки збільшується, пошукові системи роблять висновок про те, що сторінка стала менш значущою для користувача, і позиції сторінки в результатах пошуку «просідають».

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

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

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

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

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

Зміна адресації сторінок

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

Куди важливіше не допустити кардинальної зміни адресації сторінок сайту.

Під адресацією ми розуміємо URL сторінок сайту, наприклад: http://site.ru/path/folder1/page

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

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

Для наочності розберемо приклад.

Припустимо, розділ «Новини» був раніше всередині розділу «Компанія» і мав адресацію:

http://site.ru/o-kompanii/novosti

У новій версії сайту після редизайну «Новини» виносяться в головне меню в один ряд з розділом «Компанія». Змінюється положення сторінки в структурі сайту і адреса змінюється на http://site.ru/novosti .

було: http://site.ru/o-kompanii/novosti
стало: http://site.ru/novosti

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

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

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

Приклад типового редизайну:

Зовнішній вигляд сайту mkb.ru до редизайну

Зовнішній вигляд сайту mkb.ru після редизайну

Однак не поспішайте відкладати редизайн сайту. З проблемою зміни адресації можна впоратися шляхом настройки перенаправлення зі старої адреси на нову адресу - тобто за допомогою редиректів.

редіректи

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

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

Таке перенаправлення не тільки дозволяє вказати нову адресу сторінки для пошукової системи, воно говорить «тепер все те ж саме знаходиться тут». Пошукова система буквально склеює два цих адреси, вважаючи їх одним. Це дозволяє зберегти, або, як було б правильніше сказати, передати вагу (важливість) від старої сторінки до нової.

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

Все вищесказане відноситься виключно до редіректу з кодом 301. Всі інші коди редиректів в даній ситуації можуть бути марні.

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

Тут слід дотримуватися лише одного принципу: кожна стара сторінка, яка в новій версії сайту змінила свою адресу, повинна містити редирект з кодом 301 на нову адресу.

Для розглянутого вище прикладу сторінка за старою адресою http://site.ru/o-kompanii/novosti повинна містити перенаправлення з кодом 301 на адресу http://site.ru/novosti.

Тобто, якщо сторінка http://site.ru/path/folder1/page змінила адресу на http://site.ru/page, то при заході на стару адресу http://site.ru/path/folder1/page користувач (і пошуковий робот) повинен автоматично опинитися на нову адресу сторінки http://site.ru/page.

Наявність налаштованого 301 редиректу необхідно перевірити після завершення «переїзду» сайту на нову версію.

Перевірити це можна вручну, наприклад, за допомогою сервісу «» в Яндекс.Вебмастере або за допомогою масової перевірки, наприклад, в програмі

Можна також використовувати онлайн-сервіси, які дозволяють перевірити швидко і безкоштовно кілька адрес, наприклад.

Варто враховувати, що зміною адреси сторінка слід вважати навіть найменша зміна в URL. Наприклад, якщо всі сторінки сайту були з завершальним слешем «/» на кінці (напр., Http://site.ru/o-kompanii/novosti/) а після редизайну стали мати адреси без «/» (напр., Http: //site.ru/o-kompanii/novosti) це вже привід налаштувати 301 редирект.

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

Як приклад можемо навести наш корпоративний сайт «Ашманов і партнери». Раніше у нас була розроблена програма SiteAuditor, інформація про неї розміщувалася на сторінці http://www.ashmanov.com/services/siteauditor , Але з часом підтримка програми була припинена, проект закритий.

При зміні дизайну було прийнято рішення видалити цю сторінку зі структури сайту, а користувачів зі старої адреси сторінки перенаправляти на найбільш підходящий за змістом розділ - https://www.ashmanov.com/tech-i-services/ в якому знаходяться інші наші сервіси, які допомагають вирішувати суміжні завдання.

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

Таблиця відповідності адрес

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

Поточний URL Новий URL Дії / about / sertificaty / about / sertificaty не змінюється / catalog / bytovaya-tehnika / krupnaya / holodilniki / catalog / bytovaya-tehnika / holodilniki налаштувати 301 редирект / catalog / bytovaya-tehnika / krupnaya / stiralnye-mashiny / catalog / bytovaya-tehnika / stiralnye-mashiny налаштувати 301 редирект / catalog /? brand = bosch / catalog / bosch налаштувати 301 редирект / catalog / bytovaya-tehnika / krupnaya / holodilniki /? brand = bosch / catalog / bosch / bytovaya-tehnika / holodilniki налаштувати 301 редирект / catalog / bytovaya-tehnika / krupnaya / holodilniki /? brand = bosch & id = 4008_022 / catalog / bosch / bytovaya-tehnika / holodilniki / 4008_022 налаштувати 301 редирект / catalog / bytovaya-tehnika / krupnaya / holodilniki /? page = 12 / catalog / bytovaya-tehnika / holodilniki / page12 налаштувати 301 редирект / about / news /? id_new = 67663 / about / news / otkrytie-novogo-m agarina-v-moskve налаштувати 301 редирект
Таку таблицю віддайте розробникам сайту та попросіть налаштувати редирект з кодом 301 з кожної адреси в лівій колонці на відповідну адресу в другій колонці, якщо вони відрізняються один від одного. Цього буде достатньо, щоб уникнути проблем.

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

Використання JS і AJAX в новому дизайні

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

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

Найчастішою помилкою є використання в новій версії сайту елементів на скриптових мовах Java Script і / або AJAX або, що ще гірше, реалізації на цих скриптах всього контенту оновленого сайту.

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

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

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

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

Якщо вміст сторінки виводиться виключно скриптами Java Script або AJAX, пошукові роботи в деяких випадках порахують сторінку порожній!

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

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

В кінці цього розділу наводяться посилання на рекомендації з даного питання для вебмайстрів від самих пошукових систем.

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

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

Перевірити наявність скриптів Java Script або AJAX можна на етапі розробки сайту самостійно. Коли розробник нової версії сайту завершить розробку і надасть доступ до тестової версії сайту:

1. Відкрійте сторінку в браузері;
2. Віберіть в різніх Частина Сторінки кілька унікальніх словосполучень в 2-3 слова, например, заголовок, словосполучень або слова з тематічної части Сторінки, запам'ятайте або віпішіть їх;
3. Відкрійте вихідний код Сторінки в браузері (комбінація клавіш Ctrl + U в більшості браузерів або відповідній пункт меню браузера, на зразок «Дополнітелььніе інструменти / Код Сторінки»);
4. Пошукати в коді обрані слова и словосполучень (для поиска використову стандартних комбінацію клавіш Ctrl + F);
5. Повторіть пошук для всіх типів сторінок сайту (головної, сторінки головного меню, сторінки рубрики каталогу, картки товару і т.д.)
6. Якщо в коді сторінки не вдається знайти словосполучення, які ви бачите в браузері при перегляді сторінки, значить, цей текст, швидше за все, генерується на льоту, тобто виводиться за допомогою скриптів і буде не видно пошуковим системам.

Це сигнал, що варто поставити запитання розробникам сайту про максимально можливої ​​проблеми з пошуковим просуванням даних сторінок.

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

Занадто пізніше оповіщення про редизайн

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

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

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

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

зміна домену

Незважаючи на те, що зміну домену можна вважати окремим випадком зміни адрес сторінок, її варто розглянути окремо.

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

З технічної точки зору робиться це ще простіше, ніж з редирект окремих сторінок сайту. Досить розмістити кілька рядків в службовому файлі .htaccess, який є на всіх веб-серверах під управлінням .nix систем (заснованих на UNIX):

RewriteCond% {REQUEST_URI} (. *) RewriteRule ^ (. *) $ Http://novyj-site.ru/$1 [L, R = 301]

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

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

Проблеми можуть бути в тому випадку, якщо не всі сторінки старого домену будуть містити редирект на сторінки нового домену (що в цілому неможливо, якщо встановлено вищенаведений набір директив).

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

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

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

зміна протоколу

C 2017 Інтернет живе в умовах «переїзду на захищений протокол HTTPS». Пошукові системи виступають за необхідність розміщення сайтів на протоколі https: //, якщо на сторінці є функціонал особистого кабінету, оплати або будь-яких інших форм введення чутливих особистих або платіжних даних. Це забезпечує збереження і безпеку особистої інформації користувачів вашого сайту.

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

Щоб уникнути втрати позицій і видимості слід налаштувати 301 редирект з усіх сторінок на протоколі http: // на відповідні їм сторінки на протоколі https: //.

Зміна підрядника по SEO

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

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

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

Логіни і паролі для доступу. Якщо не ви самі реєстрували сайт в таких сервісах від пошукових систем, як Яндекс.Вебмайстер, Google Search Console і Кабінет вебмастер Mail.ru, то запросите доступи до них. Отримавши доступ, необхідно змінити паролі і переконатися, що ніяким зайвим акаунтів не вирішено доступ для перегляду і не делеговані права на редагування інформації. Зробити це можна в налаштуваннях облікового запису даних сервісів. У разі, якщо реєстрацію проводили ви і підряднику надавали лише перегляд даних вашого облікового запису, то краще за все видалити таку можливість.

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

Те ж саме стосується і встановлених систем аналітики - Яндекс.Метрики або Google Analytics.

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

Доступ до систем моніторингу. Аналогічним чином слід вчинити з даними вашого сайту в будь-якому сервісі моніторингу позицій сайту в пошукових системах. Уточніть у вашого поточного підрядника, в якому сервісі здійснювався збір позицій вашого сайту і попросіть передати проект на свій аккаунт в цьому сервісі.

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

Висновки

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

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

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

Корисні посилання

Довідкова інформація від пошукових систем по індексуванню сайтів, які використовують JS і AJAX:

• - інструкція Яндекса щодо вирішення проблеми індексації сайтів, які використовують JS і AJAX для виведення контенту на сторінках.
• - довідкова інформація по індексуванню сайтів на AJAX від Google.

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

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

Кабінети вебмайстрів від пошукових систем, доступи до яких необхідно мати і контролювати:

для вебмайстрів по процедурі переїзду сайту з протоколу http на https.

Главу підготував Олександр Козоріз, Head of SEO, «МедіаНація».