7 технічних проблем SEO, які ви забули перевірити

Вступ

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

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

Це не технічні срібні кулі SEO, це рекомендації, які ви знаєте, що повинні виправити, але ніколи не робите.

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

Правило перенаправлення в верхньому регістрі

Будь-який технічний SEO-спеціаліст знає про очевидні правила перенаправлення і про те, де вони повинні застосовуватися, наприклад, http на https сторінки, кінцевий слеш на некінцевий слеш і т.д.

Однак, коли ви востаннє перевіряли, що всі URL-адреси сторінок примусово використовують нижній регістр?

Оскільки URL-адреса є унікальним ідентифікатором веб-сторінки, тому www.example.com/category та www.example.com/Category вважаються різними сторінками, незважаючи на те, що їх зміст однаковий.

Це може створити проблеми з дублюванням контенту в пошукових системах, тому слід примусово використовувати малі літери в URL-адресах.

Проблеми з пагінацією

Якщо веб-сайт, яким ви керуєте, має категорійну пагінацію, то шаблон URL-адреси часто виглядає наступним чином:

www.example.com/mattresses/memory-foam-mattresses?p=1 www.example.com/mattresses/memory-foam-mattresses?p=2 www.example.com/mattresses/memory-foam-mattresses?p=3

Однак, в даному прикладі сторінка ?p=1 є дублікатом канонічної сторінки www.example.com/mattresses/memory-foam-mattresses.

Тому цей дублікат ?p=1 повинен бути 301 перенаправлений на сторінку www.example.com/mattresses/memory-foam-mattresses з оновленням всіх внутрішніх посилань, щоб відобразити цю зміну.

Ще одна проблема пагінації, про яку легко забути, пов'язана з канонічними тегами. Часто сторінки ?p=2, ?p=3 у своїх канонічних тегах посилаються на першу сторінку пагінації.

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

Використовуйте тег Meta noindex замість robots.txt

Я ПОСТІЙНО бачу повідомлення "Для цієї сторінки немає інформації " при перегляді проіндексованих сторінок в Google:

Це пов'язано з тим, що веб-майстер намагався видалити сторінку з індексу, додавши проти неї директиву disallow в robots.txt.

Однак ці сторінки все одно можуть бути знайдені пошуковими системами, тому краще видалити їх з robots.txt і додати тег noindex між тегами HEAD сторінок, які не повинні індексуватися.

Видалення мета-метафори nofollow з вибраних сторінок

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

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

Dev Site в індексі

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

Найкращий спосіб заблокувати тестове середовище від індексації - це захистити його паролем або обмежити на основі діапазону IP-адрес.

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

- Site:dev.example.com - Site:staging.example.com - Site:prod.example.com - Site:example.com inurl:test - Site:example.com -inurl:www.

Перегляньте свій XML-файл

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

Перевірка 1 - Чи є посилання на XML-карту в файлі robots.txt?

Пошукові роботи завжди шукатимуть файл robots.txt у кореневій папці веб-сайту. Тому додавання посилання на XML-карту сайту в robots.txt вказує всім основним пошуковим системам на її місцезнаходження.

Перевірка 2 - Чи було додано файл XML Sitemap до пошукової консолі Google Search Console?

Надсилання XML-карт сайтів до Пошукової консолі Google гарантує, що Google зможе їх знайти та сканувати. Після відправки ви можете побачити, чи вдалося Google виявити URL-адреси ваших сторінок:

Перевірка 3 - Чи є помилки в XML-карті сайту?

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

Ви можете дізнатися, чи є у вашій карті сайту помилки, переглянувши її в Пошуковій консолі Google після того, як карту сайту в форматі XML буде надіслано. Крім того, ви можете переглянути XML-карту сайту в Screaming Frog, вибравши " Режим" > "Список" > "Завантажити" > "Завантажити XML-карту".

Видалення старого контенту з індексу

Коли ви востаннє переглядали свій застарілий контент, наприклад, сторінки конкурсів, які закінчилися у 2017 році?

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

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

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

- Site:example.com inurl:Різдво - Site:example.com inurl:конкурс - Site:example.com inurl:премія - Site:example.com inurl:серпень - Site:example.com inurl:вересень - Site:example.com inurl:2016 - Site:example.com inurl:2017 - тощо.