суть в том что у меня были прописаны директивы на запрет сканирования мусорных страниц в robots.txt, например
Disallow: *compare/
Disallow: *?
но, толи из-за косяка в теме дизайна, то ли движка, такие мусорные страницы все равно были проиндексированы, потому что при сравнении товаров, или сортировке или фильтрации товаров в категории, на такие страницы ...
... на них формировалась как минимум одна внутренняя ссылка. А Гугл, если на запрещенную к сканированию страницу есть ссылка, запрет на сканирование отчасти игнорирует. То есть такая страница не сканируется, но индексируется. И вот у меня попало в индекс 2К такого мусора.
Если по такой мусорной странице перейти, то сервер отдает 200 ответ. Обычная такая живая страница. Хоть эти страница и были собраны динамически, они они где-то в итоге хранятся, очевидно в какой-то таблице. Вот и вопрос в какой?
Проблема в другом. С некоторых пор Гуглу глубоко по-барабану то, что указано в роботс. Он так и пишет "проиндексировано, несмотря на запрет в роботс..." Необходимо на таких страницах прописывать запрет на индексацию. К этому Гугл прислушивается.
Проблема в другом. С некоторых пор Гуглу глубоко по-барабану то, что указано в роботс. Он так и пишет "проиндексировано, несмотря на запрет в роботс..." Необходимо на таких страницах прописывать запрет на индексацию. К этому Гугл прислушивается.
1. Нет, это не с некоторых пор, это уже достаточно давно.
2. Повторюсь, страницы попадают в индекс вопреки запрета на сканирование, потому что на них есть ссылка, а ссылку на страницы сравнения товаров и страницы с использованными фильтрами/сортировками товаров за каким-то хреном вставляет движок сайта. Это подстава со стороны Webasysta. Такая же подстава как сейчас с артикульными страницами. Людям из Webasysta пофиг на SEO. И они подставляют своих клиентов, и даже не парятся по этому поводу.
3. Я сделал чтобы на таких страницах указывался мета-тег noindex, но теперь нужно пересканировать 2000 страниц, чтобы робот увидел этот тег на всех из них. Это может занять несколько месяцев. Поэтому я и хочу найти где хранятся эти страницы и тупо удалить их. Потому что есть два варианта - либо робот увидит noindeх, и удалит их из индекса, либо по ним будет 404 ответ сервера. Два варианта возможны, второй будет быстрее.
Скорее всего, вопрос терминологии. Видимо, вы имеете в виду шаблон страницы. Если говорить о странице сравнения, смотрите шаблон compare.html. Ну и т.д.
и что здесь происходит, мне непонятно ... как на страницу, которой нет в БД, но по которой сервер отдает 200, может вести внутренняя ссылка ... и где Googlebot берет информацию что на эту страницу есть ссылка, а значит ее нужно проиндексировать несмотря на запрет сканирования в robots.txt, ведь у гугла именно такой механизм индексирования страниц, которые закрыты от сканирования
эта часть url статична (страница категории)..она есть и в sitemap, и в БД (таблица shop_category)
В БД есть информация о категории. Страница же категории строится на основе шаблона category.html путем подстановки туда необходимых данных (которые берутся в т.ч. из shop_category). Если у URL есть какие-то параметры - они обрабатываются тем же шаблоном: category.html.
как на страницу, которой нет в БД, но по которой сервер отдает 200, может вести внутренняя ссылка
Ссылки тоже строятся динамически на основе тех же данных. В категории 50 товаров, а мы показываем по 10 на странице? Тогда вот ссылки на 5 страниц. 100 товаров? Тогда вот ссылки на 10 страниц. И т.п. Но по сути, это ссылки на одну и ту же страницу, с указанием в параметрах какую часть всех товаров категории отобразить.
сылку на страницы сравнения товаров и страницы с использованными фильтрами/сортировками товаров за каким-то хреном вставляет движок сайта. Это подстава со стороны Webasysta. Такая же подстава как сейчас с артикульными страницами. Людям из Webasysta пофиг на SEO. И они подставляют своих клиентов, и даже не парятся по этому поводу
Очень странное мнение. Такие ссылки нужны, чтобы посетителям сайта было удобнее пользоваться витриной. Как без них обойтись, когда товары нужно сравнить или отсортировать по цене или иному параметру? Никак.
Со стороны движка тут никакой подставы нет. Всё это в порядке вещей. Ставьте на страницы сортировки что-то типа такого условия
и проблем не будет. Попутно на таких страницах ещё ставится canonical на основной адрес категории, но это вроде и движок сделает сам, хотя вы проверьте.
плагин для проставки noindex уже поставил конечно, но там тоже есть нюансы
...
Это самая настоящая подстава ... если знать механизм индексирования Гуглом страниц которые закрыты от сканирования, вам это любой ман с компетенцией сеошника подтвердит. Ссылки может должны быть, но нужно сразу им прописывать noindex, на уровне движка, без всяких плагинов, потому что весь этот мусор летит в индекс, а между графиком мусорных страниц в индексе и количества посещений - самая прямая корреляция.
А как они всех подставили с артикульными страницами? ... вы видели сколько там 301 редиректов? Кроме того что весь этот мусор ушел в индекс и пошла жесткая просадка по посещениям, а соответственно и по продажам.
Этим чудакам просто плевать на сео, плюс у них руки из жопы в принципе, мы все это прекрасно видим ... те кто на опыте уже шарахаются от их обновлений движка как от чумы - они выпускают одно обновление ради какой-то мелочи, а потом выпускают два других обновления чтобы исправить косяки в первом обновлении.
Поменяйте движок, не насилуйте себя. Или сударь мазохист? ))
Ну и чтоб 2 раза не вставать: плевать на сео? И правильно! Потому что это ваше сео не имеетт каких-то формальных признаков и требований. Сегодня вы считаете так, завтра с точностью до наоборот, и так до бесконечности. Вам дают инструмент - научитесь им пользоваться и использовать его.
они выпускают одно обновление ради какой-то мелочи, а потом выпускают два других обновления чтобы исправить косяки в первом обновлении
Примеры спрашивать бесполезно, насколько понимаю.... Лишь бы ляпнуть. Хотя что ожидать от свидетеля сео...
Оформление вывода во многом зависит от качества проработки темы дизайна и нюансов в её шаблонах. В 99% случаев обновление движка никак не затрагивает проработанную заранее тему дизайна и вывод контента, а значит на "это ваше сео" никак не влияет.
Ещё во времена "до плагинов" всё делалось именно в теме дизайна и прекрасно работало и работает до сих пор. Обновления движка, как уже сказал ранее, никакого влияния на это не оказывают. С плагинами, наверное, стало удобнее т.к. доступность в один клик качественных решений стала выше. Сам такими не пользовался т.к. применяю свои "старые" способы.
Движок и разработчики WA дают инструмент, а как им пользоваться - это дело личное. Кому-то надо что-то закрыть, кому-то не надо... Они (разработчики платформы) об этом думать за каждого не должны. Они уже дали всё, что нужно для того, чтобы "сделать офигенно".
Методы для создания качественного сайта есть. Их разработчиками предоставлено достаточное кол-во. Просто надо изучить и применить на практике. Да, это занимает время. Возможно в процессе будут ошибки, но в итоге всё получится, если постараться.
15 ответов
Динамические страницы, вероятно, формируются на лету и отдельно в таблицах не хранятся.
Если нужно более конкретно, то опишите пример ссылки.
суть в том что у меня были прописаны директивы на запрет сканирования мусорных страниц в robots.txt, например
но, толи из-за косяка в теме дизайна, то ли движка, такие мусорные страницы все равно были проиндексированы, потому что при сравнении товаров, или сортировке или фильтрации товаров в категории, на такие страницы ...
... на них формировалась как минимум одна внутренняя ссылка. А Гугл, если на запрещенную к сканированию страницу есть ссылка, запрет на сканирование отчасти игнорирует. То есть такая страница не сканируется, но индексируется. И вот у меня попало в индекс 2К такого мусора.
Если по такой мусорной странице перейти, то сервер отдает 200 ответ. Обычная такая живая страница. Хоть эти страница и были собраны динамически, они они где-то в итоге хранятся, очевидно в какой-то таблице. Вот и вопрос в какой?
Проблема в другом. С некоторых пор Гуглу глубоко по-барабану то, что указано в роботс. Он так и пишет "проиндексировано, несмотря на запрет в роботс..." Необходимо на таких страницах прописывать запрет на индексацию. К этому Гугл прислушивается.
1. Нет, это не с некоторых пор, это уже достаточно давно.
2. Повторюсь, страницы попадают в индекс вопреки запрета на сканирование, потому что на них есть ссылка, а ссылку на страницы сравнения товаров и страницы с использованными фильтрами/сортировками товаров за каким-то хреном вставляет движок сайта. Это подстава со стороны Webasysta. Такая же подстава как сейчас с артикульными страницами. Людям из Webasysta пофиг на SEO. И они подставляют своих клиентов, и даже не парятся по этому поводу.
3. Я сделал чтобы на таких страницах указывался мета-тег noindex, но теперь нужно пересканировать 2000 страниц, чтобы робот увидел этот тег на всех из них. Это может занять несколько месяцев. Поэтому я и хочу найти где хранятся эти страницы и тупо удалить их. Потому что есть два варианта - либо робот увидит noindeх, и удалит их из индекса, либо по ним будет 404 ответ сервера. Два варианта возможны, второй будет быстрее.
Вы просто не хотите никого слышать. "С некоторых пор" != "недавно".
Все эти страницы динамические и ссылки на них не хранятся нигде. Но они есть в индексе Гугла. Оттуда их со временем уберет сам Гугл.
эээ ... серьезно, я понял что вы хотели помочь )), но щас такую чушь пишите
как по вашему на запрос страницы типа .../compare/1518,475,470,474/ может отдаваться 200 ответ сервером, если она, цитирую:
???
Может потому, что она динамическая?
Скорее всего, вопрос терминологии. Видимо, вы имеете в виду шаблон страницы. Если говорить о странице сравнения, смотрите шаблон compare.html. Ну и т.д.
эээ ....
может и вопрос терминологии
ну вот эта часть url статична (страница категории)..она есть и в sitemap, и в БД (таблица shop_category)
на эту страницу заходит пользователь, он сортирует товар в категории и создаётся новая страница, в URL которой добавляется GET-параметр
и что здесь происходит, мне непонятно ... как на страницу, которой нет в БД, но по которой сервер отдает 200, может вести внутренняя ссылка ... и где Googlebot берет информацию что на эту страницу есть ссылка, а значит ее нужно проиндексировать несмотря на запрет сканирования в robots.txt, ведь у гугла именно такой механизм индексирования страниц, которые закрыты от сканирования
А вы посмотрите на вид ссылок сортировки на странице, например, категории. Там же будет <a href=...>
Вот так Гугл и гуляет по отсортированным страницам.
В БД есть информация о категории. Страница же категории строится на основе шаблона category.html путем подстановки туда необходимых данных (которые берутся в т.ч. из shop_category). Если у URL есть какие-то параметры - они обрабатываются тем же шаблоном: category.html.
Ссылки тоже строятся динамически на основе тех же данных. В категории 50 товаров, а мы показываем по 10 на странице? Тогда вот ссылки на 5 страниц. 100 товаров? Тогда вот ссылки на 10 страниц. И т.п. Но по сути, это ссылки на одну и ту же страницу, с указанием в параметрах какую часть всех товаров категории отобразить.
Очень странное мнение. Такие ссылки нужны, чтобы посетителям сайта было удобнее пользоваться витриной. Как без них обойтись, когда товары нужно сравнить или отсортировать по цене или иному параметру? Никак.
Со стороны движка тут никакой подставы нет. Всё это в порядке вещей. Ставьте на страницы сортировки что-то типа такого условия
и проблем не будет. Попутно на таких страницах ещё ставится canonical на основной адрес категории, но это вроде и движок сделает сам, хотя вы проверьте.
плагин для проставки noindex уже поставил конечно, но там тоже есть нюансы
...
Это самая настоящая подстава ... если знать механизм индексирования Гуглом страниц которые закрыты от сканирования, вам это любой ман с компетенцией сеошника подтвердит. Ссылки может должны быть, но нужно сразу им прописывать noindex, на уровне движка, без всяких плагинов, потому что весь этот мусор летит в индекс, а между графиком мусорных страниц в индексе и количества посещений - самая прямая корреляция.
А как они всех подставили с артикульными страницами? ... вы видели сколько там 301 редиректов? Кроме того что весь этот мусор ушел в индекс и пошла жесткая просадка по посещениям, а соответственно и по продажам.
Этим чудакам просто плевать на сео, плюс у них руки из жопы в принципе, мы все это прекрасно видим ... те кто на опыте уже шарахаются от их обновлений движка как от чумы - они выпускают одно обновление ради какой-то мелочи, а потом выпускают два других обновления чтобы исправить косяки в первом обновлении.
Поменяйте движок, не насилуйте себя. Или сударь мазохист? ))
Ну и чтоб 2 раза не вставать: плевать на сео? И правильно! Потому что это ваше сео не имеетт каких-то формальных признаков и требований. Сегодня вы считаете так, завтра с точностью до наоборот, и так до бесконечности. Вам дают инструмент - научитесь им пользоваться и использовать его.
Примеры спрашивать бесполезно, насколько понимаю.... Лишь бы ляпнуть. Хотя что ожидать от свидетеля сео...
почему вы еще до сих пор не в штате Вебасиста? вы бы прекрасно дополнили их зондеркоманду
Оформление вывода во многом зависит от качества проработки темы дизайна и нюансов в её шаблонах. В 99% случаев обновление движка никак не затрагивает проработанную заранее тему дизайна и вывод контента, а значит на "это ваше сео" никак не влияет.
Ещё во времена "до плагинов" всё делалось именно в теме дизайна и прекрасно работало и работает до сих пор. Обновления движка, как уже сказал ранее, никакого влияния на это не оказывают. С плагинами, наверное, стало удобнее т.к. доступность в один клик качественных решений стала выше. Сам такими не пользовался т.к. применяю свои "старые" способы.
Движок и разработчики WA дают инструмент, а как им пользоваться - это дело личное. Кому-то надо что-то закрыть, кому-то не надо... Они (разработчики платформы) об этом думать за каждого не должны. Они уже дали всё, что нужно для того, чтобы "сделать офигенно".
Методы для создания качественного сайта есть. Их разработчиками предоставлено достаточное кол-во. Просто надо изучить и применить на практике. Да, это занимает время. Возможно в процессе будут ошибки, но в итоге всё получится, если постараться.