Остаточний посібник для Magento SEO

1. Проблеми з шаруватою / гранітною навігацією
2. Пошук сторінок
3. Мапи сайтів
4. Проблеми з переписуванням URL-адрес
5. Безпечні сторінки
6. Розбиття
7. Ідентифікатори сесії / SID
8. Продуктивність Magento
9. Переконайтеся, що використовуються 301 перенаправлення
10. Дублювати вміст продукту через декілька магазинів
11. Міжнародна орієнтація з Magento
12. Функція огляду Magento OOTB
13. Дубльований вміст, пов’язаний з каналами
14. Конфігурація Magento

Magento широко вважається одним з найбільш складних платформ електронної комерції з точки зору SEO, через складність його перезапису двигуна, опору на динамічний контент і складну кодову базу (у порівнянні з іншими платформами PHP), серед іншого. Тим не менш, всі питання SEO, пов'язані з платформою Magento, можуть бути вирішені, це просто випадок знання того, що потрібно зробити - саме тому я написав цю статтю. Багато технічних виправлень потребують ресурсу розробки, але я також рекомендую використовувати щось подібне MageWorx щоб дати вам більше контролю в Magento. Це просто робить речі трохи більш керованими (можна налаштувати hreflang, покращити канонічні URL-адреси, додати структуровані дані, призначити правила noindex тощо), ніж додавати функціональність самостійно. Раніше я випускав свій власний модуль (MageSEO), але я намагався конкурувати з їхніми рівнями підтримки і регулярними релізами (так як їх модуль є фокусом на повний робочий день, тоді як мій був побічним проектом для допомоги клієнтам).

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

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

Настроювана і проста конфігурація продукту

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

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

Канонічні URL-адреси в цілому

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

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

Умовні позначення назви продукту

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

Заголовки

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

URL-адреси продуктів

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

Переадресація

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

Проблеми з шаруватою / гранітною навігацією

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

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

Резолюції

Запобігти скануванню пошукових машин сторінок

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

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

Використовуйте noindex, слідуйте за тегом

Я регулярно вибираю директиву noindex, щоб роз'яснити пошуковим системам не індексацію шаруватих сторінок. Для цього можна використовувати теги мета-роботів або теги x роботів, і вони обидва будуть відповідати вимогам до запитів на видалення в Інструментах Google для веб-майстрів і в кінцевому підсумку подаватимуть одне й те саме повідомлення пошуковим системам.

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

Цього можна досягти за допомогою плагіна MageSEO (мого модуля Magento SEO) або більшості інших модулів - це дозволяє призначати правила ручних мета-роботів, дає вам більший контроль над канонічним тегом, а також дозволяє редагувати файл robots.txt з Magento back-end.

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

Використовуйте канонічний тег

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

Навігація AJAX

Використання навігації AJAX дозволить вам фільтрувати продукти, розміщені на вашому сайті, не змінюючи URL, залишивши лише сторінку оригінальної категорії. Якщо у вас немає досвідченого розробника Magento, це, мабуть, буде трохи кошмаром. Є модулі, які можуть допомогти з цим, але якщо чесно, якщо у вас немає хорошого розробника, я б просто не хотів робити цей перемикач. Крім того, це може викликати багато додаткових технічних проблем - я бачив, як роздрібні торговці використовують цей метод і багаторазово блокують посилання на продукт через надлишковий javascript. Якщо ви вирішили спуститися по цьому шляху (який повинен бути пов'язаний з досвідом користувачів, а також SEO), переконайтеся, що ви звернулися до досвідченого консультанта з SEO, перш ніж перейти.

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

Обробка параметрів у Google Webmaster Tools

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

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

Цьому, як правило, можна керувати дуже ефективно за допомогою MageWorx SEO Люкс - що дозволяє керувати канонічними URL-адресами (набагато всебічніше), призначати правила noindex, керувати robots.txt (а також безліччю інших речей) з back-end Magento.

Пошук сторінок

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

Мапи сайтів

Magento відомий тим, що досить сміття, коли справа доходить до створення XML Sitemaps, оскільки він просто надає можливість створення одного, автономного Sitemap, який часто містить сторінки, які ви не хочете індексувати / доступ до пошукових систем.

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

Це може бути зроблено вашими розробниками або ви можете використовувати модуль третьої сторони.

Проблеми з переписуванням URL-адрес

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

Я б рекомендував блокувати ці URL-адреси і просто стежити за ними, оскільки у мене були проблеми в минулому (викликані проблемами з оновленням), де всі URL-адреси були повернуті назад до старої структури без застосування перенаправлення 301.

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

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

Безпечні сторінки

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

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

Дубльований вміст сторінки продукту через ієрархічні URL-адреси (включаючи шлях категорії в URL-адресах)

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

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

Крім того, якщо ви переходите на продукти найвищого рівня, переконайтеся, що ваш розробник створить правило перезапису, щоб перенаправити URL-адреси старих продуктів, оскільки за замовчуванням Magento не буде перенаправляти їх.

Розбиття

Сторінки списку продуктів Magento використовують розбиття сторінок на великий список продуктів, що зазвичай означає, що той самий вміст використовується на різних варіантах однієї сторінки. На цих сторінках слід використовувати теги rel і next, які були введені компанією Google у 2011 році, щоб допомогти веб-майстрам продемонструвати, що це сторінки з розбиттям сторінок.

Тег, який можна додати до посилань за розбиттям сторінок або через <head>, виглядатиме так:

<link rel = ”далі” href = ”http://website.com/clothing?p=6> />

<link rel = ”prev” href = ”http://website.com/clothing?p=4> />

Я б запропонував використовувати noindex, слідуйте мета теги роботів поряд з rel наступного і prev.

Ідентифікатори сесії / SID

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

Якщо у вас є проблеми з ідентифікаторами сеансів, я пропоную використовувати теги файлів robots.txt або мета-роботи, щоб запобігти індексування сторінок. Це також дасть змогу надсилати запити на видалення, якщо сторінки індексуються.

Продуктивність Magento

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

• Використання оптимізованого та добре настроєного сервера
• Вимкніть журнали Magento і ввімкніть очищення журналу (у фоновому режимі Magento)
• Увімкнути об'єднання CSS і javascript (у фоновому режимі Magento)
• Використовуйте кешування веб-переглядача
• Використання CDN для зображень (також перегляньте служби стиснення зображень)
• Оптимізація активів переднього кінця

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

Переконайтеся, що використовуються 301 перенаправлення

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

Дублювати вміст продукту через декілька магазинів

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

Міжнародна орієнтація з Magento

З тих чи інших причин, торговці Magento, здається, дійсно борються з міжнародними реалізаціями магазину з точки зору SEO. Найбільш поширеною конфігурацією, яку я бачу, є торговці, які використовують один каталог і використовують розширення для додавання додаткових полів back-end (тобто залишок сторінки залишається незмінним) або використовуючи мульти-магазин і роблячи помилку, використовуючи ті самі URL-адреси, метадані , копіювати (в деяких місцях) і просто створювати варіанти для різних країн, які вони хочуть націлити.

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

Я б запропонував використовувати сторінки з різними магазинами, до яких вони не мають унікального вмісту, а також використовуючи тег hreflang, який наведено нижче. Ви можете зробити це за допомогою підкаталогу або окремих CCtlds. Тег href-lang повинен бути реалізований таким чином, щоб на еквівалентну URL-адресу посилалися з інших магазинів на основі рівня сторінки - я бачу дуже багато сайтів, які лише посилаються на домашню сторінку на кожній сторінці сайту.

Використовуючи тег hreflang з Magento

Тег rel альтернативний hreflang допомагає користувачам повідомляти Google, що у вас є альтернативна міжнародна версія даної сторінки і є основною частиною міжнародного SEO. Тег hreflang допоможе переконатися, що правильна версія сайту або окремої сторінки подається в потрібній регіональній версії Google.

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

<link rel = "alternate" hreflang = ”en-gb” href = ”http://www.example.co.uk”>

<link rel = ”alternate” hreflang = ”en-au” href = ”http://www.example.com.au”>

<link rel = "alternate" hreflang = ”fr-fr” href = ”http://www.example.fr”>

Якщо ви робите це в тому ж домені, це буде виглядати так (це використовує приклад продукту):

<link rel = "alternate" hreflang = ”en-gb” href = ”http://www.example.co.uk/example-product-1 ″>

<link rel = ”alternate” hreflang = ”en-au” href = ”http://www.example.com.au/example-product-1 ″>

<link rel = ”alternate” hreflang = ”fr-fr” href = ”http://www.example.fr/example-product-1 ″>

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

Функція огляду Magento OOTB

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

Ось приклад того, як виглядають ці сторінки:

Наявність агрегованої сторінки для перегляду вмісту досить поширене, і більшість основних постачальників перевірок роблять це за допомогою реалізації OOTB (наприклад, BazaarVoice, Yotpo і Power Reviews, щоб назвати декілька). Це те, що потрібно пам'ятати, хоча ці сторінки можуть викликати багато проблем.

Дубльований вміст, пов’язаний з каналами

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

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

Конфігурація Magento

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

Нижче наведено деякі рекомендації, які я зазвичай роблю для налаштування магазину Magento:

• Увімкнути канонічні URL-адреси для сторінок продуктів і категорій (конфіг> каталог> пошукова оптимізація)
• Встановіть URL-адреси продуктів на верхній рівень (config> каталог> пошукова оптимізація - дозвольте шлях категорії в URL-адресах продуктів, встановіть значення "no")
• Увімкніть XML-карту сайту та створіть принаймні один (каталог> Google Sitemap)
• Якщо ви використовуєте режим списку для сторінок списку продуктів (не дозволяйте відображати вміст продукту)
• Увімкніть створення переадресацій, коли URL-адреси змінюються (але стежте за перезаписами, якщо числа додаються до URL-адрес)

Конфігурація Robots.txt з Magento

Файл robots.txt є дуже цінним, особливо для великих веб-сайтів електронної комерції, але він також може викликати проблеми з фрагментацією сканування, якщо їх використовувати неправильно. Я пропоную лише використовувати файл robots.txt, якщо ви бажаєте / потребуєте пошукових систем, щоб не сканувати певні розділи веб-сайту (наприклад, сторінки пошуку, сторінки з ідентифікаторами сеансів, багаторівневу багаторівневу навігацію тощо). Для запобігання скануванню сторінок слід використовувати файл robots.txt, але пам'ятаєте, що існують інші шляхи для блокування сторінок (багато продавців Magento, здається, блокують все через файл robots.txt через деякі попередні шаблони robots.txt, які були випущені) .

Як правило, я пропоную вам заблокувати наступне, використовуючи файл robots.txt:

• Каталог пошукових сторінок
• / каталог / URL-адреси (якщо у вас немає зображень і CSS & JS у цій папці)
• URL-адреси з параметрами ідентифікатора сеансу
• Розгорнуті сторінки навігації (якщо у вас є фільтри з кількома вибраними або великий веб-сайт)
• Параметри сортування / замовлення
• Адміністративні сторінки

Отже, якщо ви будете слідувати цьому, ви robots.txt виглядатиме приблизно так (я використовую * у випадку, якщо у вас є декілька магазинів під підкаталогами):

User-agent: *

Disallow: / admin /
Заборонити: * ціна = *
Заборонити: * dir = *
Заборонити: * замовлення = *
Заборонити: * limit = *
Disallow: * / каталог / *
Заборонити: * / каталог пошуку / *
Заборонити: * / клієнт / *
Заборонити: * SID = *

Мапа сайту: ###

Модулі Magento SEO:

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

The Модуль MageWorx пропонує величезну кількість функцій SEO, включаючи:

• Підтримка Hreflang - включає безліч опцій, щоб переконатися, що вона відповідає налаштуванням каталогу вашого магазину
• Параметри для налаштування каталогу продукції - це найчастіше потрібна функція, де продавці мають декілька версій одного й того ж продукту, як правило, прості, в комплекті або настроювані продукти. Модуль дозволяє конфігурувати канонічні URL-адреси для по суті посилання на первинні версії URL-адреси. Так, наприклад, якщо у вас є сорочка, що є конфігурованим продуктом з різними розмірами версій, як прості продукти, ви можете встановити канонічну URL-адресу до конфігурованої версії кожного з них.
• Правила для правил мета-роботів - це функція, яку я використовую у всіх магазинах, на яких я працюю. Ви можете встановити правила (з символами підстановки), щоб призначити директиви тегів мета-роботів групам сторінок (наприклад, noindex, слідуйте всім URL-адресам, що містять? Price =).
• Можливість редагування файлу robots.txt з інтерфейсу Magento
• Контролюйте повторювані URL-адреси https / http
• Можливість створювати більш розширені правила для канонічних URL-адрес (для таких речей, як кінцеві риси тощо)
• Параметри перезапису URL-адрес
• Параметри створення спільних мета-заголовків (на різних сторінках)
• Розширені параметри мапи сайту XML
• Параметри розбивки
• Можливість перевизначити інші налаштування на рівні магазину

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

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

Якщо у вас виникли питання щодо налаштування, надішліть мені листа електронною поштою ( [захищена електронною поштою] ).

Інші модулі, які я використовував раніше, були досить хорошими:

• CreareSEO (безкоштовно, але менше функцій, ніж більшість преміум-класів - все-таки основи)
• Модуль мапи сайту MageWorx (це корисно як окремий модуль для розширення мапи сайту Magento)
• Модуль Mirasvit (хороший модуль, що охоплює основи з декількома додатковими опціями)

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

-

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

Пов'язані