BlagFurer

BlagFurer
Рейтинг
79
Регистрация
09.12.2009
anebilitsa:
Универсальный парсер сайтов, который будет максимально подробно (и с графиками) показывать структуру внутренней перелинковки сайта и битые ссылки.

Пытаюсь представить кейс как использовать этот инструмент. Сюдя по всему даже если реализовать его, то кроме графического представления стат веса на сраницу больше ничего из него не увидеть. И чем вам page-weight не угодил? Страница - вес... по каждой циферки которые отличаются друг от друга иногда на сотые. В общем кейса такого парсера, единственной особенностью которого будет графическое представление связей между страницами не могу придумать.

А вот кейс в котором оптимизатору нужно следить за соответствием кучи запросов документу в разных его зонах я вполне могу представить.

Большинство софта на рынке SEO смотрит на задачи оптимизатора как то однобоко. Либо видим запросы и их позиции (снималки позиций, кластеризаторы, анализаторы конкурентов), либо видим ошибки в технике сайта по страницам (парсеры во всех их видах, анализаторы индексации)... но нет такого что бы видели пару запрос - документ + анализ в каких именно местах документ соответствует запросу и сколько раз. Уже спрашивал подобный софт тут /ru/forum/950526

Elbuy:
Подскажите пожалуйста может кто сталкивался.

Ежедневно сталкиваюсь на клиентских сайтах. Дубли зло. Смотрите как решали эту проблему на крупных сайтах типа https://www.wildberries.ru/

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

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

nospamno:
подскажите как расшифровать данный robots.txt - что запрещает, что разрешает?

Вам уже ответили в отдельной теме /ru/forum/comment/14759336

Запрет индексации всех категорий на сайте кроме

site.ru?любаябелеберда

А так же дали грамотный совет использовать https://webmaster.yandex.ru/tools/robotstxt/

Ольга777:
в robots закрыта индексация папки с формами. Туда и планировалось закинуть файл меню.

Мои подозрения подтвердились.

User-agent: *
Disallow: includes/menu.inc

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

Иными словами:

Из чего состоит сайт

Файл шапки + файл меню + файлы тела + файлы чего то там в вашем движке = html страничка

То что не видит ПС

Файл шапки + файл меню + файлы тела + файлы чего то там в вашем движке

То что видят ПС и пользователи.

html страничка

Вывод закрывать серверные файлы, отвечающие за вывод страницы нет смысла, так как кроме вас их никто не видит.

PS отдельно меню от индексации можно закрыть только тегами <noindex>меню</noindex> да и то только от яндекса.

Ольга777:
Подскажите, пожалуйста, стоит ли закрывать файл с меню в User-agent?

Расскажите, как вы собираетесь это сделать? Просто интересно.

Samba1982:
такое чувство что сделан редирект на 404 страницу

Ваше чувство не совпадает со скриншотом.

1. Распарсить SeoScreaminFrog - посмотреть, что он выдаст по этим URL

2. Если ошибок не будет, то лезьте в head сайта и смотрите по каким хитрым ссылкам ходит xenu

Хотите, чтобы вам помогли покажите URL.

tron2:
Добрый день, актуально еще? Отправил резюме на e-mail.

Актуально, пишите.

kleindberg:
Мы когда-то делали что-то подобное, решили проблему через 301 редирект, по типу старая ссылка > новая ссылка для основных ссылок. Кое-чем пришлось пожертвовать.

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

Другой вариант только сохранять URL в новой CMS.

Не силен в WP но на одном сайте нашел описание

Сервис PingBack также требует свою директиву:

<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.

Уверен, что причина падения позиций не в этом файле. А для своего спокойствия просто удалите эту строку их шаблона:

<link rel="pingback" href="http://fishcom67.ru/xmlrpc.php" />

Если уверены, что на старые URL не внутренних ссылок (желательно проверить и поправить) и что пользователи не понатыкали закладок на старые страницы, старые страницы не продвигались а так же на них совсем нет трафика хотя бы за полгода, то можно удалить.

Однако я не могу припомнить ситуации, когда 301 кому то помешал.

Всего: 85