Розв'язання технічних питань SEO часто викликає розчарування, особливо коли ви вирішуєте проблему того самого сайту знову і знову. І я припускаю, що я не одна; Є кілька веб-сайтів, які страждають від цієї проблеми. У цьому пості я спробував окреслити деякі загальні проблеми, з якими я зіткнувся з життєздатними рішеннями.
Випуск №1: URL верхньої літери в порівнянні з малою URL
Веб-сайти .NET є найпоширенішою жертвою цієї проблеми. Сервер налаштовується таким чином, що він реагує на URL-адреси верхнього регістру, не перенаправляючи їх (і вам не доведеться переписувати) до рядкових URL-адрес. Тим не менш, пошукові системи тепер стали кращими у виборі такої канонічної версії, а також у ігноруванні дублікатів. Це вирішило проблему до певної міри, хоча є багато прикладів, коли пошукові системи не змогли виконати це завдання належним чином. Таким чином, все ще важливо зробити це явним, а не покладатися на пошукові системи, щоб з'ясувати це самі.
Вирішіть: скористайтеся модулем перезапису URL, щоб вирішити цю проблему на серверах IIS 7. Цей інструмент поставляється з можливістю в межах свого інтерфейсу, що дозволяє користувачеві застосовувати URL-адреси нижнього регістру. Після цього інструмент додасть правило до веб-файлу налаштувань, вирішивши проблему.
Випуск №2: Кілька версій домашньої сторінки
Це також є більш поширеним для веб-сайтів .NET, але також відбувається на інших платформах. Переглядаючи свій сайт, перевірте, чи є дублікат вашої домашньої сторінки. Щоб перевірити його, просто введіть www.yourwebsite.com/ default.aspx АБО www.yourwebsite.com/ index.html АБО www.yourwebsite.com/home
Пошукові системи можуть знайти цей дублікат домашньої сторінки за допомогою XML-мапи сайту або навігації. Ви можете легко вирішити цю проблему, не вдаючись у деталі про те, як ці сторінки генеруються.
Рішення: Рішення цієї проблеми часто залежить від гри вгадування, оскільки різні платформи генерують різні структури URL, що ускладнює пошук цих сторінок. Найкращим рішенням є сканування вашого веб-сайту та вивчення його у форматі CSV. Тепер відфільтруйте сканування у стовпці заголовка META, щоб знайти назву домашньої сторінки. Таким чином, ви можете легко знайти дублікати сторінок домашньої сторінки вашого сайту. Крім того, ви можете додати перенаправлення 301 до цих дубльованих сторінок, які вказують на правильну сторінку. Я також бачив багато вирішення цієї проблеми з rel = canonical tag.
Багато використовують такі інструменти, як Screaming Frog для сканування сайту для пошуку внутрішніх посилань на цю дубльовану сторінку. Це гарна ідея, щоб входити і редагувати ці дубльовані сторінки прямо, щоб вони вказували на правильний URL. Це допомагає уникнути втрати справедливості зв'язків, що є спільною проблемою, коли внутрішні посилання проходять через 301.
Випуск 3: Помилки 404
Дуже поширена проблема з веб-сайтами, хоча користувачі навряд чи помітять різницю. На жаль, сканери пошукових систем знають це. М'яка 404-сторінка виглядає як звичайна сторінка помилки 404, але вона повертає код статусу HTTP 200. Хоча користувач побачить більше тексту, окрім рядка «Сторінка не знайдена», код 200 повідомляє пошуковим системам, що сторінка працює правильно. В результаті, пошукові системи будуть сканувати та індексувати навіть ті сторінки, які ви хотіли б сховати від сканерів.
Але за лаштунками код 200 говорить пошуковим системам, що сторінка працює правильно. Це розрив може призвести до проблем зі скануванням та індексуванням сторінок, якщо ви не хочете, щоб вони були.
М'який 404 також означає, що ви не можете виявити справжні розбиті сторінки та визначити області вашого сайту, де користувачі отримують поганий досвід. Від a побудова посилання перспектива (я повинен був згадати це десь!), ні рішення є гарним варіантом. Ви можете мати вхідні посилання на недійсні URL-адреси, але посилання буде важко відстежити та перенаправити на правильну сторінку.
Як вирішити:
На щастя, це відносно просто виправлення для розробника, який може встановити сторінку, щоб повернути код статусу 404 замість 200. Поки ви там, ви можете весело провести час і створити 404 сторінку для задоволення вашого користувача. Ось кілька прикладів 404 сторінок, які я маю на увазі.
Щоб знайти програмне забезпечення 404, можна скористатися функцією в Інструментах Google для веб-майстрів, яка розповість вам про ті, які Google виявив:
Ви також можете виконати перевірку вручну, перейшовши до зламаної URL-адреси на своєму сайті (наприклад, www.example.com/5435fdfdfd) і дізнавшись, який код статусу ви отримаєте. Інструмент, який мені дуже подобається для перевірки коду статусу, є Web Sniffer, або ви можете використовувати інструмент Ayima, якщо ви використовуєте Google Chrome.
302 перенаправлення замість 301 перенаправлення
Знову ж таки, це легке перенаправлення для розробників, щоб помилитися, оскільки, з точки зору користувача, вони не можуть визначити різницю. Тим не менше, пошукові системи відносяться до цих переадресацій дуже по-різному. Тільки для того, щоб нагадати, перенаправлення 301 є постійним і пошукові системи будуть розглядати його як таку; вони передадуть посилання на нову сторінку. Переадресація 302 - це тимчасова перенаправлення, і пошукові системи не передадуть посилання на зв'язок, тому що вони очікують, що початкова сторінка повернеться в певний момент.
Як вирішити:
Щоб знайти 302 перенаправлені URL-адреси, я рекомендую використовувати глибокий сканер, такий як Screaming Frog або IIS SEO Toolkit. Потім можна фільтрувати за 302s і перевіряти, чи дійсно вони повинні бути 302s, або якщо вони повинні бути 301s замість.
Щоб усунути проблему, потрібно попросити розробників змінити правило, щоб скористатися перенаправленням 301, а не перенаправленням 302.