anebilitsa: Универсальный парсер сайтов, который будет максимально подробно (и с графиками) показывать структуру внутренней перелинковки сайта и битые ссылки.
Пытаюсь представить кейс как использовать этот инструмент. Сюдя по всему даже если реализовать его, то кроме графического представления стат веса на сраницу больше ничего из него не увидеть. И чем вам page-weight не угодил? Страница - вес... по каждой циферки которые отличаются друг от друга иногда на сотые. В общем кейса такого парсера, единственной особенностью которого будет графическое представление связей между страницами не могу придумать.
А вот кейс в котором оптимизатору нужно следить за соответствием кучи запросов документу в разных его зонах я вполне могу представить.
Большинство софта на рынке SEO смотрит на задачи оптимизатора как то однобоко. Либо видим запросы и их позиции (снималки позиций, кластеризаторы, анализаторы конкурентов), либо видим ошибки в технике сайта по страницам (парсеры во всех их видах, анализаторы индексации)... но нет такого что бы видели пару запрос - документ + анализ в каких именно местах документ соответствует запросу и сколько раз. Уже спрашивал подобный софт тут /ru/forum/950526
Elbuy: Подскажите пожалуйста может кто сталкивался.
Ежедневно сталкиваюсь на клиентских сайтах. Дубли зло. Смотрите как решали эту проблему на крупных сайтах типа https://www.wildberries.ru/
У товара должна быть только одна страница. На уровне движка вы выставляете основную категорию, в которой будет товар и от которой строится чпу. Другие категории - дополнительные. Косяк у этой схемы один и он самый очевидный. Пользователь, находясь в дополнительной категории переходит в товар и видит в крошках путь от основной категории. Упомянутый выше сайт решил эту проблему путем хитрых манипуляций на стороне клиента. В реальности все товары там строятся от бренда.
Если на удобстве пользователя особо не морочиться, то просто стройте крошки от основной категории и не плодите дубли.
Ольга777: в robots закрыта индексация папки с формами. Туда и планировалось закинуть файл меню.
Мои подозрения подтвердились.
User-agent: *
Disallow: includes/menu.inc
Файл, который отвечает за вывод меню не доступен поисковым машинам, так как является серверным. Поисковая машина может увидеть только результат работы вашего файла с меню - то есть саму страницу html.
Иными словами:
Из чего состоит сайт
Файл шапки + файл меню + файлы тела + файлы чего то там в вашем движке = html страничка
То что не видит ПС
Файл шапки + файл меню + файлы тела + файлы чего то там в вашем движке
То что видят ПС и пользователи.
html страничка
Вывод закрывать серверные файлы, отвечающие за вывод страницы нет смысла, так как кроме вас их никто не видит.
PS отдельно меню от индексации можно закрыть только тегами <noindex>меню</noindex> да и то только от яндекса.
kleindberg: Мы когда-то делали что-то подобное, решили проблему через 301 редирект, по типу старая ссылка > новая ссылка для основных ссылок. Кое-чем пришлось пожертвовать.
Если страниц ну скажем до 1000 и допускаете, что небольшая часть трафика и позиций может быть потеряна при перезде, то смело пишите новые редиректы.
<link rel="pingback" href="http://www.sdelaysite.com/xmlrpc.php"> Вкратце PingBack работает следующим образом:
— Ваш друг поставил ссылку в своем блоге на одну из ваших публикаций. — Если в блоге включен механизм обратных уведомлений, блог вашего друга постарается отправить информацию о ссылке вам. — Адрес, на который нужно передать информацию о внешней ссылке, указан либо в рассматриваемой директиве, либо в заголовках сервера (см. рис. 1., пункт X-Pingback). — После получения информации о внешней ссылке на адрес http://vash_blog.ru/xmlrpc.php ваш блог может опубликовать данные обратной ссылки либо в комментариях, либо в админке.
Судя по всему ваш файл http://fishcom67.ru/xmlrpc.php когда-то лежавший в корне сайта канул в лету. Отчего и генерирует 405 код.
Обычно парсеры не обращают внимания на ссылки в head, а ходят по внутренним ссылкам. Так у меня и моего коллеги SeoMotion, парсеры не нашли ошибок, а XENU почему то решил заглянуть в head.
Уверен, что причина падения позиций не в этом файле. А для своего спокойствия просто удалите эту строку их шаблона:
Если уверены, что на старые URL не внутренних ссылок (желательно проверить и поправить) и что пользователи не понатыкали закладок на старые страницы, старые страницы не продвигались а так же на них совсем нет трафика хотя бы за полгода, то можно удалить.
Однако я не могу припомнить ситуации, когда 301 кому то помешал.
Универсальный парсер сайтов, который будет максимально подробно (и с графиками) показывать структуру внутренней перелинковки сайта и битые ссылки.
Пытаюсь представить кейс как использовать этот инструмент. Сюдя по всему даже если реализовать его, то кроме графического представления стат веса на сраницу больше ничего из него не увидеть. И чем вам page-weight не угодил? Страница - вес... по каждой циферки которые отличаются друг от друга иногда на сотые. В общем кейса такого парсера, единственной особенностью которого будет графическое представление связей между страницами не могу придумать.
А вот кейс в котором оптимизатору нужно следить за соответствием кучи запросов документу в разных его зонах я вполне могу представить.
Большинство софта на рынке SEO смотрит на задачи оптимизатора как то однобоко. Либо видим запросы и их позиции (снималки позиций, кластеризаторы, анализаторы конкурентов), либо видим ошибки в технике сайта по страницам (парсеры во всех их видах, анализаторы индексации)... но нет такого что бы видели пару запрос - документ + анализ в каких именно местах документ соответствует запросу и сколько раз. Уже спрашивал подобный софт тут /ru/forum/950526
Подскажите пожалуйста может кто сталкивался.
Ежедневно сталкиваюсь на клиентских сайтах. Дубли зло. Смотрите как решали эту проблему на крупных сайтах типа https://www.wildberries.ru/
У товара должна быть только одна страница. На уровне движка вы выставляете основную категорию, в которой будет товар и от которой строится чпу. Другие категории - дополнительные. Косяк у этой схемы один и он самый очевидный. Пользователь, находясь в дополнительной категории переходит в товар и видит в крошках путь от основной категории. Упомянутый выше сайт решил эту проблему путем хитрых манипуляций на стороне клиента. В реальности все товары там строятся от бренда.
Если на удобстве пользователя особо не морочиться, то просто стройте крошки от основной категории и не плодите дубли.
подскажите как расшифровать данный robots.txt - что запрещает, что разрешает?
Вам уже ответили в отдельной теме /ru/forum/comment/14759336
Запрет индексации всех категорий на сайте кроме
site.ru?любаябелеберда
А так же дали грамотный совет использовать https://webmaster.yandex.ru/tools/robotstxt/
в robots закрыта индексация папки с формами. Туда и планировалось закинуть файл меню.
Мои подозрения подтвердились.
Disallow: includes/menu.inc
Файл, который отвечает за вывод меню не доступен поисковым машинам, так как является серверным. Поисковая машина может увидеть только результат работы вашего файла с меню - то есть саму страницу html.
Иными словами:
Из чего состоит сайт
Файл шапки + файл меню + файлы тела + файлы чего то там в вашем движке = html страничка
То что не видит ПС
Файл шапки + файл меню + файлы тела + файлы чего то там в вашем движке
То что видят ПС и пользователи.
html страничка
Вывод закрывать серверные файлы, отвечающие за вывод страницы нет смысла, так как кроме вас их никто не видит.
PS отдельно меню от индексации можно закрыть только тегами <noindex>меню</noindex> да и то только от яндекса.
Подскажите, пожалуйста, стоит ли закрывать файл с меню в User-agent?
Расскажите, как вы собираетесь это сделать? Просто интересно.
такое чувство что сделан редирект на 404 страницу
Ваше чувство не совпадает со скриншотом.
1. Распарсить SeoScreaminFrog - посмотреть, что он выдаст по этим URL
2. Если ошибок не будет, то лезьте в head сайта и смотрите по каким хитрым ссылкам ходит xenu
Хотите, чтобы вам помогли покажите URL.
Добрый день, актуально еще? Отправил резюме на e-mail.
Актуально, пишите.
Мы когда-то делали что-то подобное, решили проблему через 301 редирект, по типу старая ссылка > новая ссылка для основных ссылок. Кое-чем пришлось пожертвовать.
Если страниц ну скажем до 1000 и допускаете, что небольшая часть трафика и позиций может быть потеряна при перезде, то смело пишите новые редиректы.
Другой вариант только сохранять URL в новой CMS.
Не силен в WP но на одном сайте нашел описание
<link rel="pingback" href="http://www.sdelaysite.com/xmlrpc.php">
Вкратце PingBack работает следующим образом:
— Ваш друг поставил ссылку в своем блоге на одну из ваших публикаций.
— Если в блоге включен механизм обратных уведомлений, блог вашего друга постарается отправить информацию о ссылке вам.
— Адрес, на который нужно передать информацию о внешней ссылке, указан либо в рассматриваемой директиве, либо в заголовках сервера (см. рис. 1., пункт X-Pingback).
— После получения информации о внешней ссылке на адрес http://vash_blog.ru/xmlrpc.php ваш блог может опубликовать данные обратной ссылки либо в комментариях, либо в админке.
Судя по всему ваш файл http://fishcom67.ru/xmlrpc.php когда-то лежавший в корне сайта канул в лету. Отчего и генерирует 405 код.
Теперь про источник проблемы. Корень зла находится тут https://yadi.sk/i/_l3aWAJrxKKGk
Обычно парсеры не обращают внимания на ссылки в head, а ходят по внутренним ссылкам. Так у меня и моего коллеги SeoMotion, парсеры не нашли ошибок, а XENU почему то решил заглянуть в head.
Уверен, что причина падения позиций не в этом файле. А для своего спокойствия просто удалите эту строку их шаблона:
Если уверены, что на старые URL не внутренних ссылок (желательно проверить и поправить) и что пользователи не понатыкали закладок на старые страницы, старые страницы не продвигались а так же на них совсем нет трафика хотя бы за полгода, то можно удалить.
Однако я не могу припомнить ситуации, когда 301 кому то помешал.