Для главной страницы создается дубликат! Страница без слеша и со слешем в конце отдается с кодом 200 - дублируется.
Для главной страницы поисковая система не может сделать дубликат в рамках одного протокола и домена. Это технически не возможно. Значит вы либо не правильно высказались, либо соврали, либо я не прав, и готов увидеть поисковый запрос, где на один домен две главных: со слешем, и без.
Кстати, в вашей первой ссылке вывод про слеши такой:
Какой URL предпочтителен: со слешем или без? Чисто технически — никакой разницы. Смотрите по ситуации: если проиндексировано больше страниц со слешем, оставляйте этот вариант, и наоборот.
А не как вы сказали:
1. Слеш влияет
В любом случае, я думаю ещё долго владельцы бизнеса будут искать причины низкой посещаемости, подозревая слэш на главной :)
Всегда нужно ссылаться на официальные рекомендации Google/Yandex, а не на чьи-то домыслы.
P.S. Без обид, очень часто работаю с сеошниками, и часто приходиться смотреть на эти бредовые рекомендации, которые иногда даже реализовать невозможно, не нарушая RFC и стандарты Web.
Здравствуйте, Сергей! А с чего вы взяли, что со слешем и без для главной должны быть разные статусы? Я конечно понимаю, что вы SEOшник, но это не освобождает вас от знания технической части того, как работает web.
Во-первых, в заголовках при запросе главной страницы слеш всегда подставляется, веб-сервер не знает, со слешем вы запросили URL, или нет, так как к нему запрос всегда приходит со слешем.
Во-вторых, в блоге Google специально для SEOшников написано:
Rest assured that for your root URL specifically, http://example.com is equivalent to http://example.com/ and can’t be redirected even if you’re Chuck Norris.
Там же сказано на счет других страниц (не главных):
Leave it as-is. Many sites have duplicate content. Our indexing process often handles this case for webmasters and users. While it’s not totally optimal behavior, it’s perfectly legitimate and a-okay. :)
Попробуйте сосредоточить ваши SEO навыки на чем-то полезном, а не бессмысленных попытках заставить веб-сервер делать то, для чего он не предназначен.
Не знаю, актуально для вас или нет, но писал для тех, кто задастся таким же вопросом в будущем.
Подтверждайте проблему, появилась после обновления. Я уже писал workaround чтобы поля отобразились - нужно выбрать витрину. Без витрины не подгружаются нужные поля, их попросту нету в теле AJAX ответа.
Есть решение, вот тут работает, все автоматизировано. Работает по тому же принципу, как и генерация миниатюр, только в двух режимах - локально, и по API на моем сервере.
У меня есть готовый плагин для WebP, работает уже месяца три на боевом магазине, и почти готов под инсталлер, но руки не дойдут его туда опубликовать. Работает через облако (мой сервер по API конвертирует), или через энкодер установленный на сервере. Разница в весе картинок -75% где-то, если картинки обычные и не сжатые через tinypng. У этого формата есть ещё несколько преимуществ, он грузится не блокируя рендеринг и не вызывая перерисовку страниц, т.к. размер картинки передается в хидере файла.
Ленивую подгрузку картинок легко реализовать самому, тут работает уже как года 3.
Под отложенную загрузку картинок можно использовать Intersection Observer API.
Править код и структуру БД, тем самым потерять обновления.
Давить на Webasyst, чтобы они перешли на "лесенку" в shop_category_product и переехали на InnoDB, и переписали часть запросов, чтобы использовался, например, покрывающий индекс там, где это возможно. Этот пункт можете сразу отбрасывать.
Спасибо, я знаю что плагин рабочий. Файлы фреймворка и приложений не правились, скриншоты событий я скинул, я так понимаю, что все должно работать, но почему-то не работает. Вот я и спрашиваю, есть ли у кого-то идеи почему? Может была подобная ситуация.
Сложность реализации данной штуки ставит под сомнение её целесообразность. Если вам кто-то и возьмется это делать, то ценник будет такой, что мне кажется, что пустота на последней строчке станет не такой уж критичной, а будет вполне себе ничего.
Если что, не забывайте обновлять приложение сайт, иначе ссылка в инсталлере будет вести на страницу сайта, которая в свою очередь не будет доступна, пока не установишь обновление сайта.
Перед тем, как переписывать запрос, нужно видеть его план выполнения.
UPD: Это у вас динамические категории, если я не ошибаюсь? Если да, то лучше отказывайтесь от них на таком количестве товаров. Как альтернативу динамическим категориям, в магазине есть плагин, автоматизирующий рутину (например, добавление товаров в категории при выполнении какого-то условия). Думаю что он вам подойдет, почитайте описание про него.
Системный администратор говорит что сервер настроен правильно
Скиньте конфиг my.cnf сюда, глянем что можно придумать. У Shop-Script специфика в том, что тут на многих таблицах до сих пор используется движок MyISAM, и тюнить базу нужно под него.
Сам по себе Shop-Script - коробочное решение. Коробочные решение обычно плохо подходят под большое количество данных и трафика.
Если вам нужно ускорить именно поиск, то смотрите в сторону Sphinx, ElasticSearch, Solr/Lucene. Малой кровью тут обойтись не получится, придется написать код и настроить софт.
Быстрый поиск по 400 000 товарам на MySQL вряд ли возможен, учитывая то, что он генерирует табличку с на порядок бОльшим количеством записей, по которой идет поиск.
Если хотите ускорить сайт, то при таком количестве товаров целесообразно вынести саму базу на отдельный хост, чтобы не делить I/O с PHP и другими приложениями.
Также посоветовал бы уйти от Apache в сторону nginx, и обновить версию PHP, хотя бы до 7.0. Так сайту будет легче дышать.
Это самое первое, что нужно предпринять, чтобы сайт стал работать шустрее.
Я слышал историю, что владелец битрикса это внучатый племянник Сергея Брина, и они на свадьбе одного из родственников согласовали, что, мол, {if dvizhok == "bitrix"} position += 100 {/if}, прям так в коде и прописали.
А если серьезно: если код одинаков побайтово, то и позиция должна быть одна на двоих? Я даже так скажу вам. Поставьте две копии битрикса, с одним и тем-же дизайном, залейте туда одни и те же товары, и через время вы увидите, что позиции будут различаться. Там более 200 факторов ранжирования, не включая коммерческие. История домена, серые IP, и т.д.
Извиняюсь за долгий ответ, написал в поддержку - сейчас плагин должен быть снова доступен для установки.
https://www.webasyst.ru/store/plugin/shop/singleskuname/
в ответ на Наименование артикула для одиночного артикула
Вы писали:
Для главной страницы поисковая система не может сделать дубликат в рамках одного протокола и домена. Это технически не возможно. Значит вы либо не правильно высказались, либо соврали, либо я не прав, и готов увидеть поисковый запрос, где на один домен две главных: со слешем, и без.
Кстати, в вашей первой ссылке вывод про слеши такой:
А не как вы сказали:
В любом случае, я думаю ещё долго владельцы бизнеса будут искать причины низкой посещаемости, подозревая слэш на главной :)
Всегда нужно ссылаться на официальные рекомендации Google/Yandex, а не на чьи-то домыслы.
P.S. Без обид, очень часто работаю с сеошниками, и часто приходиться смотреть на эти бредовые рекомендации, которые иногда даже реализовать невозможно, не нарушая RFC и стандарты Web.
в ответ на NGINX: слеш в конце
Здравствуйте, Сергей! А с чего вы взяли, что со слешем и без для главной должны быть разные статусы? Я конечно понимаю, что вы SEOшник, но это не освобождает вас от знания технической части того, как работает web.
Во-первых, в заголовках при запросе главной страницы слеш всегда подставляется, веб-сервер не знает, со слешем вы запросили URL, или нет, так как к нему запрос всегда приходит со слешем.
Во-вторых, в блоге Google специально для SEOшников написано:
Там же сказано на счет других страниц (не главных):
Попробуйте сосредоточить ваши SEO навыки на чем-то полезном, а не бессмысленных попытках заставить веб-сервер делать то, для чего он не предназначен.
Не знаю, актуально для вас или нет, но писал для тех, кто задастся таким же вопросом в будущем.
в ответ на NGINX: слеш в конце
Поправьте, пожалуйста. Очень неудобно все писать в один абзац.
в ответ на Редактор. Обращение в службу поддержки.
Pomodoro + Trello.
в ответ на Что Вы делаете, чтобы сосредоточится на задачах и Вас ничего не отвлекало от работы?
Кеш чистил, не помогает. ID запроса в поддержке: 1466145
в ответ на Пропали поля при оформлении заказа в бекенде
Не полностью откатили, или откатили на момент, когда в заказ уже попали массивы а не строки.
в ответ на Телефон и почта в заказах не видны.
Подтверждайте проблему, появилась после обновления. Я уже писал workaround чтобы поля отобразились - нужно выбрать витрину. Без витрины не подгружаются нужные поля, их попросту нету в теле AJAX ответа.
в ответ на Пропали поля при оформлении заказа в бекенде
Есть проблема. Ждем фикс.
в ответ на АХТУНГ! Последнее обновление шоп скрипт - ошибка фильтра
Подтверждаю проблему. Помогает выбор витрины рядом с источником покупателя.
в ответ на Оформление заказа имя покупателя
Можно закрывать, проблема была на нашей стороне.
в ответ на CommerceML - пустые данные о заказах
Есть решение, вот тут работает, все автоматизировано. Работает по тому же принципу, как и генерация миниатюр, только в двух режимах - локально, и по API на моем сервере.
в ответ на webp
Тогда пожелаю вам успехов!
в ответ на Отложенная загрузка изображений на страницах темы, как лучше организовать.
У меня есть готовый плагин для WebP, работает уже месяца три на боевом магазине, и почти готов под инсталлер, но руки не дойдут его туда опубликовать. Работает через облако (мой сервер по API конвертирует), или через энкодер установленный на сервере. Разница в весе картинок -75% где-то, если картинки обычные и не сжатые через tinypng. У этого формата есть ещё несколько преимуществ, он грузится не блокируя рендеринг и не вызывая перерисовку страниц, т.к. размер картинки передается в хидере файла.
Ленивую подгрузку картинок легко реализовать самому, тут работает уже как года 3.
Под отложенную загрузку картинок можно использовать Intersection Observer API.
в ответ на Отложенная загрузка изображений на страницах темы, как лучше организовать.
Для начала, уйти из облака на хостинг или VPS.
в ответ на Скорость загрузки сайта
Попробуйте почитать это, так как раз по фильтрам есть совет.
https://developers.webasyst.ru...
Если в кратце, решений несколько:
в ответ на Быстрый говорили они...
Код чего выкладывать? Фреймворка? Плагина? Там все стандартное.
Может кому-то пригодиться, проблема была в том, что не сработал install.php. После переустановки плагина все заработало.
в ответ на Не работает Workflow, почему?
Спасибо, я знаю что плагин рабочий. Файлы фреймворка и приложений не правились, скриншоты событий я скинул, я так понимаю, что все должно работать, но почему-то не работает. Вот я и спрашиваю, есть ли у кого-то идеи почему? Может была подобная ситуация.
в ответ на Не работает Workflow, почему?
Почитайте вот эту тему, может вам будет полезно.
Нужно создать один индекс, и по возможности переехать на другой движок таблиц (делайте на свой страх ириски). С этим уже можно будет жить.
Сомневаюсь, что в близжайшее время вебасист сменит дизайн БД.
в ответ на SQL запрос вешает mysql
Сложность реализации данной штуки ставит под сомнение её целесообразность. Если вам кто-то и возьмется это делать, то ценник будет такой, что мне кажется, что пустота на последней строчке станет не такой уж критичной, а будет вполне себе ничего.
в ответ на Запрограммировать вывод динамичного кол-ва товаров в категории
Плагин принудительно отображающий поле с артикулом (бесплатный)
https://www.webasyst.ru/store/...
в ответ на Наименование артикула для одиночного артикула
То же самое наблюдаю на одном магазине. Скорее всего, кто-то брутом обзавелся.
в ответ на Не удалось войти в магазин
Если что, не забывайте обновлять приложение сайт, иначе ссылка в инсталлере будет вести на страницу сайта, которая в свою очередь не будет доступна, пока не установишь обновление сайта.
в ответ на Вышло обновление фреймворка до 1.9.0.272 и Сайта до кучи и появилось новое (!) в Структуре сайта
Попробуйте поставить дефолтную тему. Поотключайте плагины. Если не поможет - разверните бекап на другом хостинге.
в ответ на Почему тормозит сайт???
Какая версия MySQL?
Перед тем, как переписывать запрос, нужно видеть его план выполнения.
UPD: Это у вас динамические категории, если я не ошибаюсь? Если да, то лучше отказывайтесь от них на таком количестве товаров. Как альтернативу динамическим категориям, в магазине есть плагин, автоматизирующий рутину (например, добавление товаров в категории при выполнении какого-то условия). Думаю что он вам подойдет, почитайте описание про него.
Скиньте конфиг my.cnf сюда, глянем что можно придумать. У Shop-Script специфика в том, что тут на многих таблицах до сих пор используется движок MyISAM, и тюнить базу нужно под него.
Сам по себе Shop-Script - коробочное решение. Коробочные решение обычно плохо подходят под большое количество данных и трафика.
Диски у вас SSD?
в ответ на Медленная скорость работы с большим количество товаров. Править Движок ?
Отпишите мне на почту danforth@live.ru, обсудим с вами.
в ответ на как ускорить поиск shopscript?
Если вам нужно ускорить именно поиск, то смотрите в сторону Sphinx, ElasticSearch, Solr/Lucene. Малой кровью тут обойтись не получится, придется написать код и настроить софт.
Быстрый поиск по 400 000 товарам на MySQL вряд ли возможен, учитывая то, что он генерирует табличку с на порядок бОльшим количеством записей, по которой идет поиск.
Если хотите ускорить сайт, то при таком количестве товаров целесообразно вынести саму базу на отдельный хост, чтобы не делить I/O с PHP и другими приложениями.
Также посоветовал бы уйти от Apache в сторону nginx, и обновить версию PHP, хотя бы до 7.0. Так сайту будет легче дышать.
Это самое первое, что нужно предпринять, чтобы сайт стал работать шустрее.
в ответ на как ускорить поиск shopscript?
В sitemap.xml приложений «Блог» и «Сайт» нету записей скорее всего потому, что в них вообще нету никаких записей.
Для магазина карта сайта разбивается по 50 000 записей (по крайней мере должна), т.к. это требования поисковых систем.
В robotx.txt лучше всего внести основной sitemap.xml, предварительно попытаться скрыть приложения Сайт и Блог (если они вам не нунжы).
в ответ на sitemap.xml
Я слышал историю, что владелец битрикса это внучатый племянник Сергея Брина, и они на свадьбе одного из родственников согласовали, что, мол, {if dvizhok == "bitrix"} position += 100 {/if}, прям так в коде и прописали.
А если серьезно: если код одинаков побайтово, то и позиция должна быть одна на двоих? Я даже так скажу вам. Поставьте две копии битрикса, с одним и тем-же дизайном, залейте туда одни и те же товары, и через время вы увидите, что позиции будут различаться. Там более 200 факторов ранжирования, не включая коммерческие. История домена, серые IP, и т.д.
в ответ на Bitrix и Webasyst позиции в поисковиках.
Приветствую! Опубликовали плагин: https://www.webasyst.ru/store/plugin/shop/bestsale...
Умеет все то, что вы перечислили.
Скидка 15%: J5IL4P0VUC до 14.07.2017.
в ответ на Хиты продаж