Полное руководство по SEO Magento

  1. Слоистые / граненые проблемы навигации
  2. Поиск страниц
  3. Sitemaps
  4. Проблемы с перезаписью URL
  5. Безопасные страницы
  6. пагинация
  7. Идентификаторы / идентификаторы сеансов
  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 или Enterprise.

Конфигурируемая и простая конфигурация продукта

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

Если вы не намеренно создаете простые продукты и добавляете дополнительный уникальный контент на страницы, я бы предложил использовать канонический тег, чтобы проиллюстрировать, что простые продукты являются вариантами основного настраиваемого продукта.

Канонические URL в целом

В бэкэнде Magento есть опции для установки канонического тега для отображения на страницах товаров и категорий, что гарантирует, что канонический тег всегда будет указывать на основную версию этих страниц. Это «должно» помочь предотвратить проблемы с динамическими вариантами индексации категорий, однако в большинстве случаев это не так, потому что страницы очень разные. Если вы не добавляете специальную реализацию канонического тега, я бы предложил включить обе эти опции, которые можно найти в разделе конфигурации интерфейса администратора Magento.

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

Соглашения о тегах названий товаров

Еще одним соображением является то, как Magento присваивает теги заголовка продукта, которые обычно являются просто названием продукта. Я бы предложил либо установить соглашение, включающее переменные, основанные на характеристиках (например, пол, цвет и т. Д.), Либо назначить их вручную, что всегда будет предпочтением.

Заголовки

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

URL продукта

Я бы предложил настроить реализацию Magento для использования URL-адресов продуктов верхнего уровня, а не выбирать вариант включения пути категории в URL-адреса. Я расскажу об этом более подробно позже.

Перенаправление

В серверной части Magento есть возможность установить постоянные перенаправления, если URL-адрес изменен, - я бы рекомендовал установить для него значение yes, хотя просто имейте в виду потенциальные проблемы с перезаписью, если вы регулярно вносите изменения в ключи URL-адреса или делаете это. CSV загружает неправильно. Опять же, это будет описано более подробно позже.

Слоистые / граненые проблемы навигации

Многоуровневая или многогранная навигация очень часто вызывает проблемы с дублированным содержимым в Magento, поскольку фильтры, создающие новые URL, часто индексируются поисковыми системами. Magento из коробки добавляет параметры фильтра строки запроса, но ряд непатентованных модулей также используют каталоги и различные другие соглашения, которые все еще приводят к тому же результату. Это особенно важно, если вы используете Amasty или Manadev.

Одна из самых больших ошибок, которую я вижу у ритейлеров в электронной коммерции, - это просто изменение динамического соглашения, на котором основаны URL-адреса и мета-заголовки, - таким образом, эффективно делая URL-адрес чистым и делая тег заголовка чуть более целевым. Это не очень хорошая идея, так как из-за большого количества индексируемых страниц низкого качества веб-сайт становится уязвимым для Google Panda, который специально нацелен на сайты с высоким уровнем индексируемых страниц с очень небольшим количеством уникального контента.

Решения

Запретить поисковым системам сканировать страницы

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

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

Используйте noindex, следуйте тегу

Я регулярно использую директиву noindex, чтобы запретить поисковым системам индексировать многоуровневые страницы навигации. Для этого можно использовать теги meta robots или x robots, и они все равно будут удовлетворять требованиям для запросов на удаление в Инструментах Google для веб-мастеров и в конечном итоге будут отправлять одно и то же сообщение поисковым системам.

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

Это может быть достигнуто с помощью плагина 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 (а также множеством других вещей) из серверной части Magento.

Поиск страниц

Другая очень раздражающая проблема с Magento - это когда Google выполняет поиск по страницам в каталоге, как правило, их тысячи. Чтобы предотвратить это, я бы просто рекомендовал запретить присваивание noindex, следуйте тегам meta robots на странице поиска и дочерним запросам, содержащимся в каталоге. Если у вас возникли проблемы с бюджетом сканирования, я бы предложил использовать файл robots.txt вместо мета-тегов robots.

Sitemaps

Magento известен тем, что он довольно мусор, когда дело доходит до создания XML-файлов сайтов, поскольку он просто предоставляет возможность создания одного автономного файла Sitemap, который часто содержит страницы, которые вы не хотите, чтобы поисковые системы проиндексировали их / стали доступными.

Я обычно предлагаю создать два XML-файла Sitemap, один для продуктов и один для категорий и страниц контента - это обеспечивает лучшую видимость индексации страниц (с помощью Инструментов Google для веб-мастеров), а также упрощает доступ Google ко всем вашим страницам, если у вас есть большой сайт. Для очень больших веб-сайтов я обычно советую разделять продукты по брендам или типам, чтобы еще раз лучше понять индексацию. Затем вы будете ссылаться на разные карты сайта в индексной карте сайта.

Это может быть сделано вашими разработчиками или вы можете использовать сторонний модуль.

Проблемы с перезаписью URL

Еще одна удивительно распространенная проблема с Magento - перезапись URL-адресов, которая может привести к тому, что URL-адреса страниц категорий или продуктов вернутся к исходным / catalog / 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 и prev, который был введен Google в 2011 году, чтобы помочь веб-мастерам проиллюстрировать, что они являются страницами с нумерацией страниц.

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

<link rel = ”next” href = ”http://website.com/clothing?p=6 ″ />

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

Я бы предложил использовать noindex, следуйте метатегам вместе с rel next и prev.

Идентификаторы / идентификаторы сеансов

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

Если у вас есть проблемы с идентификаторами сеансов, я бы предложил использовать файл robots.txt или метатеги robots для предотвращения индексации страниц. Это также позволит вам отправлять запросы на удаление, если страницы проиндексированы.

Производительность Magento

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

  • Использование оптимизированного и хорошо настроенного сервера
  • Отключить журналы Magento и включить очистку журналов (в бэкэнде Magento)
  • Включить слияние CSS и javascript (в бэкэнде Magento)
  • Используйте кеширование в браузере
  • Использование CDN для изображений (также посмотрите сервисы сжатия изображений)
  • Оптимизация внешних активов

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

Убедитесь, что 301 перенаправления используются

По умолчанию более старые версии Magento используют перенаправления 302 по умолчанию, что предотвратит переадресацию и переписывание правил для передачи значения. Я настоятельно рекомендую убедиться, что ваши перенаправления установлены на 301, чтобы обеспечить максимальную отдачу от вашей ссылки.

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

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

Международный таргетинг с Magento

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

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

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

Использование тега hreflang с Magento

Тег rel alternate hreflang помогает пользователям сообщить Google, что у вас есть альтернативная международная версия данной страницы, и является фундаментальной частью международного SEO. Тег hreflang поможет обеспечить правильную версию сайта или отдельной страницы в правильной региональной версии Google.

Есть несколько доступных модулей, однако я не использовал ни один из них должным образом, поэтому я бы предложил использовать ваш ресурс разработки для его реализации. Сама реализация будет отличаться в зависимости от того, используете ли вы несколько магазинов или реализуете международные страницы через плагин или настраиваемые поля. Вот пример (с использованием различных CCtld) того, как он должен выглядеть, если он реализован правильно на странице (также может быть сделано через ваш 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-адреса для страниц товаров и категорий (config> каталог> поисковая оптимизация)
  • Установите URL-адреса продуктов на верхнем уровне (config> каталог> поисковая оптимизация - разрешите путь к категории в URL-адресах продуктов, установите «нет»)
  • Включить XML-карту сайта и создать хотя бы одну (каталог> Google Sitemap)
  • Если вы используете режим списка для страниц со списком продуктов (не разрешать отображать содержимое продукта)
  • Включите создание перенаправлений при изменении URL-адресов (но следите за перезаписью, если числа добавляются к URL-адресам)

Конфигурация Robots.txt с Magento

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

Я бы вообще предложил вам заблокировать следующее с помощью файла robots.txt:

  • Каталог поиска страниц
  • / catalog / URLs (если в этой папке нет изображений и CSS & JS)
  • URL с параметрами идентификатора сессии
  • Многоуровневая навигация по страницам (если у вас несколько фильтров или большой веб-сайт)
  • Параметры сортировки / заказа
  • Страницы администратора

Так что, если вы будете следовать этому, ваш robots.txt будет выглядеть примерно так (я использую * в случае, если у вас есть несколько магазинов в подкаталогах):

Пользователь-агент: *

Disallow: / admin /
Disallow: * цена = *
Disallow: * dir = *
Disallow: * заказ = *
Disallow: * limit = *
Запретить: * / каталог / *
Disallow: * / catalogsearch / *
Запретить: * / клиент / *
Disallow: * SID = *

Карта сайта: ###

Модули SEO Magento:

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

Модуль MageWorx предлагает огромное количество функций SEO, в том числе:

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

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

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

Если у вас есть вопросы по настройке - напишите мне ( [электронная почта защищена] ).

Другие модули, которые я использовал до этого, были довольно хорошими:

  • CreareSEO (бесплатно, но меньше функций, чем у большинства премиальных - хотя и делает основы)
  • Модуль карты сайта MageWorx (это полезно в качестве отдельного модуля для расширения карты сайта Magento)
  • Модуль Мирасвит (хороший модуль, который охватывает основы с несколькими дополнительными опциями)

Я тоже это написал Magento SEO модуль сравнения чтобы было проще определиться с тем, какой модуль использовать.

-

Если у вас есть какие-либо вопросы обо всем, что я упомянул в этом сообщении в блоге или что-либо еще, связанное с Magento, пожалуйста напишите мне через эту форму , Я также предоставляю Magento SEO аудит и консалтинг для крупных проектов Magento.

связанные с

Com/clothing?
Com/clothing?
Например, noindex, следуйте по всем URL-адресам, содержащим?