Yesvik

Вот ссылка где более менее внятно описаны хлебные крошки как дополнительный элемент навигации по сайту https://blog.promopult.ru/sales/chto-takoe-xlebnye-kroshki-i-dlya-chego-oni-nuzhny.html Но в этой статье не полностью раскрыта тема использования ссылки типа кнопки Назад. Попробую пояснить подробнее... Когда покупатель попадает на страницу товара из поиска или по отбору через фильтр - хлебные крошки позволяют перейти в категорию, к которой принадлежит данный товар, для просмотра аналогичных товаров, но при этом теряются параметры отбора/поиска, которые он задал... именно для таких случаев используется ссылка типа кнопки Назад - для возврата на страницу с результатами отбора/поиска. Ещё раз повторю - нельзя заменять хлебные крошки историей навигации. Историю навигации надо использовать как дополнительный элемент, который вместе с хлебными крошками помогает покупателю.

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

Рассмотрим группу товаров Плойки... Плойки бывают для завивки волос и для выпрямления волос. У нас есть товар Плойка утюжок для выпрямления волос, который отображается в категории Плойки и категории Плойки -> Утюжки. Покупатель заходит в категорию Плойки, кликает на товар Плойка утюжок и в хлебных крошках получает просто Плойки, а должен получить Плойки -> Утюжки. Зачем покупателю плойки для завивки волос если он явно ищет плойку для выпрямления волос?

Заполни эту ячейку

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

https://www.sitemaps.org/ru/protocol.html

Не понятна суть вопроса... <h1 style="text-align: center;">ИНТЕРНЕТ &ndash; МАГАЗИН ОДЕЖДЫ</h1> С точки зрения валидности - всё корректно, но... Заголовок - это блочный элемент и занимают всю доступную ширину. Для выравнивания заголовка существует атрибут align и его CSS аналог text-align. На сколько оправдано наличие оформления в разметке сложно ответить по приведённому примеру. Если речь не идёт о простенькой странице - то разметку и оформление надо разделять. Как оформить заголовок с помощью CSS тебе уже накидали вариантов.

Судя по обсуждению все прочитали это и решили реализовать алгоритм в прайсе объявить enable_auto_discounts в элементе shop ежедневно в 23:00 изменять цены по API ежедневно в 07:00 отменять цены установленные по API Если речь идёт про 100 товаров - почти рабочий алгоритм, только не забывайте про человеческий фактор и технические проблемы... Сценарий человеческого фактора: в 23:00, по крону, в базе снижаются цены, по API передали сниженные цены и т.д., но Маркет продолжает ходить на сайт за прайсом и после 23:00 получает прайс в котором снижены цены. Т.е. в 07:00 кроме отмены цен надо сообщить Маркету что изменился прайс... и вот тут может прилететь нежданчик. В ночи было скучно сеошнику или контентщику и они изменили что-то из списка Понятно когда цены вернутся в исходное состояние? Теперь про случай когда речь идёт про десятки тысяч товаров - для 10000 товаров процедура установки и отмены цен займёт не менее 7 часов Так что API не вариант для данного случая. При использовании API вы не можете четко контролировать время изменения цен, сигналы о снижении и повышении цен подаются отдельно... подумайте что будет если по техническим причинам не пройдёт сигнал о возврате цен в исходное состояние. Поэтому смотрите в сторону методов, позволяющих одновременно передать информацию о начале и окончании акции https://yandex.ru/support/partnermarket/elements/promo-flash.html

Если речь идёт не про 100 товаров, а про тысячи или десятки тысяч - расскажу как вся затея сведётся к нулю или в откровенную подставу перед Яндексом или поставщиком.

Этот финт ушами со скидками Яша не пропустит... а при проверке качества - можно и на санкции нарваться

Проблема 100% с некорректным переходом на https, загружается только html и логотип Если разрешить браузеру загружать http - загружаются стили, скрипты и т.д.

Похоже вопрос вообще не про меню, а по поводу штатного функционала... Тут надо смотреть catalog/controller/product/category.php catalog/view/theme/ТВОЯ_ТЕМА/template/product/category.tpl и если есть system/storage/modification/catalog/controller/product/category.php system/storage/modification/catalog/view/theme/ТВОЯ_ТЕМА/template/product/category.tpl

А в 1С как характеристики заведены?

Т.е. ты, в споре о противоречиях рекомендаций Гугл и Яндекс, говорил про страницы с изменённым порядком сортировки, с изменённым количеством товаров на странице и т.д., считая именно эти страницы дублями. А если рассматривать этот пример ты не считаешь страницы пагинации дублями. Я правильно тебя понял?

В модулях Яндекса реализованы simple и vendor.model. Если понадобится реализация под виды товаров/услуг не реализованных в модулях от Яндекса - обращайтесь.

Очень хочется узнать радиус изгиба рук того кто это сделал. 2 минуты генерится страница... на фоне этого загрузка изображений - пыль Готов за посмотреть найти причину тормозов.

Кстати на этом сайте: Каждая страница пагинации каноническая В тайтл добавлен номер страницы Дескрипшен выводится только на первой странице категории Описание категории выводится только на первой странице категории Посмотрите какие позиции у сайта.

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

Google отказался от prev/next, а не от canonical. Google говорит что лучше выдавать портянки с сотнями товаров... но для большинства присутствующих на этом форуме - это проблема, даже с отложенной загрузкой. Если у тебя на странице будет большое количество товаров - вот тебе и значимое количество текста для уникализации каждой страницы пагинации, можно смело отказаться от описания категории. Но тайтлы и дескрипшены всёравно надо уникализировать. Твоё замечание по поводу разбиения на микрокатегории справедливо для случая когда все товары из подкатегорий бездумно вывалены в вышестоящую категорию, а если подойти к этому с умом - можно сделать определённый срез товаров и разложить их по разным страницам вышестоящей категории. Смотри, у тебя есть 5 подкатегорий, в каждой подкатегории делаешь хитрый порядок сортировки. В первой категории начинаешь с 1000, во второй с 2000, в третей с 3000, в четвертой с 4000 и в пятой с 5000. Какой категории какую тысячу отдать - выбираешь исходя из того на какой странице вышестоящей категории хочешь отображать группу товаров из каждой подкатегории. Если у тебя по дефолту 25 товаров на странице - выводишь по 25 товаров из каждой подкатегории в вышестоящую категорию. Это не означает что надо первые 25 товаров из подкатегории отображать в вышестоящей, это могут быть товары с порядком сортировки 1001, 1024, 1376, 1459 и т.д. И это не означает что надо рандомно надёргать 25 товаров из подкатегории, товары отбираются по какому-то объединяющему их признаку. В итоге в вышестоящей категории у тебя на каждой странице пагинации будет по 25 товаров из каждой подкатегории отобранных по какому-то признаку.

Я не знаю почему вы так решили. Ах да, наверное вот из-за этого: Нет трафика и... продолжайте... нет? ну давайте я за вас продолжу сам и процитирую из своего поста выше: На одни и те же грабли уже какую страницу наступаете... Так же как и Саша. Дальше вы зацикливаетесь именно на трафике, но упускаете инфу про дубли... Так я тоже против))) К чему это было?))) В 95% случаев метод каноникализации из Опенкарт 2 - вполне себе пригоден. Вы вообще знаете отличие каноникал Опенкарт 2 от Опенкарт 3? Именно с этого и тема пошла, что автору темы нужно было сделать в тройке, как в двойке, и он не мог 2 страницы перенести код из контроллера категории двойки в тройку...  Так как скорее всего сеошники увидели что страницы листинга ссылаются сами на себя и товары безобразны и страницы листинга могут склеится так как их контент во много однообразен и похож, вот они и очканули и напрягли разраба переделать как в двойке... Каждая написанная тобой строчка - ложь и попытки выкрутиться. На первой странице категории товары с 1 по 10 и этих товаров нет на на других страницах категории. На второй странице категории товары с 11 по 20 и этих товаров нет на на других страницах категории.. На третьей странице категории товары с 21 по 30 и этих товаров нет на на других страницах категории.. Это три разные страницы, но... Первая страница отличается от второй и третьей только набором товаров и параметром в URL указывающем на номер страницы. Вторая страница отличается от первой и третьей только набором товаров и параметром в URL указывающем на номер страницы. Третья страница отличается от первой и второй только набором товаров и параметром в URL указывающем на номер страницы. Яндекс рекомендует с помощью тега rel="canonical" сообщать поисковому боту, что вторая и третья страница является дублем первой страницы. Если ты считаешь рекомендации Яндекса правильными - значит вторую и третью страницу ты считаешь дублями первой. Ржу до слёз... Я рекомендую уникализировать каждую страницу пагинации и забить на rel="canonical", но ты не согласен и предлагаешь вторую и последующие страницы пагинации считать дублями. Утрируя твою извращённую логику, привожу пример. На первой странице категории "А" 10 товаров которых нет в категории "Б" На первой странице категории "Б" 10 товаров которых нет в категории "А" Эти страницы отличаются параметром в URL указывающем на категорию, но при этом параметр указывающий на номер страницы одинаковый. Кроме набора товаров у этих страниц отличаются тайтлы, дескрипшены и описание категорий. По твоей логике это тоже дубли? Ведь ты не согласен с моими рекомендациями по уникализации каждой страницы пагинации. Я знаю, а ты не знаешь и пудришь людям мозг своими фантазиями. Автору темы не надо как в Opencart 2, автору темы надо как рекомендует Яндекс... вот с чего поднялась тема! Чтобы всем было понятно твое "знание" Opencart опишу что и как реализовано в Opencart 2, Opencart 3 и что хотел автор темы... Opencart 3 Первая страница пагинации: canonical на себя и next на вторую страницу Вторая страница пагинации: canonical на себя, prev на первую страницу и next на третью страницу Третья страница пагинации: canonical на себя, prev на вторую страницу и next на четвертую страницу Последняя страница пагинации: canonical на себя и prev на предпоследнюю страницу Т.е. каждая страница пагинации считается уникальной, но при этом остаются не уникальные тайтлы, дескрипшен, описание категории. Opencart 2 Первая страница пагинации: canonical на себя и next на вторую страницу Вторая страница пагинации: canonical нет, но есть prev на первую страницу и next на третью страницу Третья страница пагинации: canonical нет, но есть prev на вторую страницу и next на четвертую страницу Последняя страница пагинации: canonical нет, есть только prev на предпоследнюю страницу Т.е. canonical на второй и последующих страницах не объявляется, но это не означает что страницы не канонические. Страница становится не канонической когда в качестве канонической указывается другая страница. По сути эта реализация не отличается от Opencart 3, потому что нет канонических объявлений на другие страницы, но есть не уникальные тайтлы, дескрипшены и описания, которые я рекомендую уникализировать и тогда можно не заморачиваться с каноникал в постраничной навигации. Хотелка ТС Первая страница пагинации: canonical на себя и next на вторую страницу Вторая страница пагинации: canonical на первую страницу, prev на первую страницу и next на третью страницу Третья страница пагинации: canonical на первую страницу, prev на вторую страницу и next на четвертую страницу Последняя страница пагинации: canonicalна первую страницу и prev на предпоследнюю страницу Т.е. это точная реализация рекомендаций Яндекса... первая страница уникальная, а остальные страницы пагинации - дубли первой страницы. Это гораздо хуже того, как сделано и в Opencart 2 и в Opencart 3. Комментировать остальные наезды балобола не представляется возможным из за отсутствия аргументации.

Это не про папки, а про пункты меню в англоязычной версии В русскоязычной версии это Система -> Инструменты -> Журнал ошибок Если искать в папках: system/storage/logs/error.log

Всё правильно, на каждой странице уникальная часть целого! Зачем ставить каноникал на первую страницу и говорить поисковику, что 10 товаров со второй, третьей и т.д. страниц - это тоже самое что и 10 товаров на первой странице? А Яндекс призывает именно к этому и пудрит мозг оговоркой - если на эти страницы нет трафика. А что делать если есть трафик? Если в подкатегории товаров на 2-3 страницы, то в принципе можно ограничиться и первой страницей. Но если на сайте выстроена иерархия, в которой товары по категориям распределены от корневых категорий до подкатегорий по принципу от общего к частному и речь идёт о корневой категории в которую выведены определённые товары из подкатегорий, с учетом дефолтного количества разбиения на страницы - я против того чтобы в результатах поиска была только первая страница. Что значит не говорили? Конкретно разъясняли, что не важно о чем речь... о статье или о товарах. Такое впечатление, что ты не внимательно слушал ответ представителя Гугл и вводишь в заблуждение неподготовленных пользователей... Привожу стенографию речи представителя Гугл из видеовстречи с вебмастерами с 15:33 по 17:17 Представитель Гугл мягко говорит - "не рекомендуем", а в блоге Гугл написано почему не рекомендуют - в результатах поиска будет только первая страница. И Яндекс, в своих рекомендациях, говорит, что в результатах поиска будет только первая страница. Повторяю - меня не устраивают рекомендации ни Гугла, ни Яндекса... если сделать страницу со всеми товарами - эту страницу поисковики забракуют из за тормозов. Варианты когда одна страница категории в результатах поиска и ничего не делать, пусть поисковик сам разбирается - меня тоже не устраивают. По сути, на каждой странице постраничной навигации уникальная группа товаров, которых нет на других страницах постраничной навигации, но из за текстового окружения в виде шапки, подвала, боковой панели, описания категории, одинаковых тайтлов и дескрипшена - страницы могут признать дублями, потому что страницы различаются не значительно. Поэтому надо уникализировать каждую страницу в цепочке постраничной навигации, закрыть страницы с изменённым порядком сортировки, с изменённым количеством товаров на странице и не париться с каноникал. Доказывать что я внимательно читаю и слушаю больше не хочу и не буду.

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

История гораздо веселее ) Гугл уже несколько лет не поддерживает prev/next, а в марте признались...

Нет, не читал. Если есть тема с выкладками - кинь сюда или в личку. А то что индексирующий робот знает о дублях и постоянно по ним шарится - это понятно.