Как получить полный список страниц сайта, включая страницы-сироты.


vataga_a
168

Приветствую. Данный вопрос уже не раз обсуждался на форуме, однако в этих темах у людей была немного другая задача. 

Необходимо получать именно полный список страниц сайта, включая страницы, на которые не ведут внутренние ссылки (так называемые » страницы-сироты«). Особенно важно определять такие страницы. То есть, парсеры, онлайн-генераторы sitemap здесь не подходят, поскольку они парсят страницы, переходя по ссылкам.

Есть советы подключать к парсерам через API системы аналитики, например,  в Screaming Frog подключить Google Аналитику. Хороший совет, как правило код аналитики устанавливается на все страницы сайта через header, но проблема в том, что на такие страницы «одиночки» может не быть переходов, а значит и в статистику они не попадут.

Есть конечно еще вариант sitemap-плагины в самой CMS, но это не всегда удобно, потому что не все типы сайтов подойдут для такого.

Поэтому хотелось бы узнать есть ли еще какие-то способы получения полного списка страниц, включая страницы-сироты.

Буду благодарен, если кто-нибудь поделиться опытом.


totamon

для начала определитесь вы «свои» страницы ищете или «чужие»? вроде как подключение аналитики и  sitemap-плагины подразумевают что «свои», но обычно использование CMS и так подразумевает контроль содержимого сайта,  можно написать небольшой скрипт который по известным алгоритмам выдаст все страницы из базы данных. если «чужие» то смириться — не все, что хочется и приходит в голову, можно реализовать не прибегая к мистике😀


vataga_a

totamon #:
для начала определитесь вы «свои» страницы ищете или «чужие»? вроде как подключение аналитики и  sitemap-плагины подразумевают что «свои», но обычно использование CMS и так подразумевает контроль содержимого сайта,  можно написать небольшой скрипт который по известным алгоритмам выдаст все страницы из базы данных. если «чужие» то смириться — не все, что хочется и приходит в голову, можно реализовать не прибегая к мистике😀

Клиентские, то есть чужие 😊 Задача — анализ индексации сайта. Просто хотел уточнить, нет ли другого способа помимо указанных. То есть клиентам можно говорить, что другого варианта нет получить максимально полный список страниц, кроме как из базы данных при помощи плагина или скрипта?


miketomlin

vataga_a #:
То есть клиентам можно говорить, что другого варианта нет получить максимально полный список страниц, кроме как из базы данных при помощи плагина или скрипта?

Да, конечно.


Vladimir SEO

а хену разве не сканит весь сайт ?


Антоний Казанский

vataga_a #:
Клиентские, то есть чужие 😊 Задача — анализ индексации сайта.

В этому случае имеет смысл анализировать только те веб страницы к которым есть навигационный доступ. Страницы «сироты» которые вы описали сейчас практически не встречаются, если они генерируются движком, значит логика навигационной связи должны быть. Раньше, когда сайты делались без CMS и страницы линковались вручную, то такие страницы встречались, но данного анахронизма я не встречал уже лет 10. 

Вообще сама по себе идея искать подобные страницы не имеет практической ценности. Разве, что предположить, что на клиентский сайт в отдельный раздел закачали вредоностный дор или чужие рекламные страницы (не так давно подобная практика была довольно распространена) и к ним с клиенского сайта действительно не было доступа (их проталкивали в индекс внешними ссылками), но здесь поможет только анализ индексного содержимого, но если учесть, что есть в какой-то папке еще подобные паразитные страницы, то без прямого доступа к сайту вы их никак не обнаружите.

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


Антоний Казанский

Vladimir SEO #:
а хену разве не сканит весь сайт ?

Xenu такой же программный краулер как и остальные — ходит по доступным на сайте ссылкам и кстати, нередко при дефольных настройках выдает неправильный код ответа сервера.


vataga_a

anthony_ #:

В этому случае имеет смысл анализировать только те веб страницы к которым есть навигационный доступ. Страницы «сироты» которые вы описали сейчас практически не встречаются, если они генерируются движком, значит логика навигационной связи должны быть. Раньше, когда сайты делались без CMS и страницы линковались вручную, то такие страницы встречались, но данного анахронизма я не встречал уже лет 10. 

Вообще сама по себе идея искать подобные страницы не имеет практической ценности. Разве, что предположить, что на клиентский сайт в отдельный раздел закачали вредоностный дор или чужие рекламные страницы (не так давно подобная практика была довольно распространена) и к ним с клиенского сайта действительно не было доступа (их проталкивали в индекс внешними ссылками), но здесь поможет только анализ индексного содержимого, но если учесть, что есть в какой-то папке еще подобные паразитные страницы, то без прямого доступа к сайту вы их никак не обнаружите.

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

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

Что касается страниц-сирот, то у меня встречаются подобные случаи, такие страницы удается находить при помощи подключения sitemap в парсинг краулером, при условии что sitemap как раз сгенерирован силами самой CMS.

Как образуются такие страницы, не всегда понятно. Ну например, создается страница без директории, чтобы ссылка была с минимум уровнем вложенности (site.ru/stranica1), но забывают связать данную страницу структурно, либо перелинковкой. То есть на сайте присутствуют страницы, до которых краулер физически добраться не может, но при этом эти страницы имеют контент, предполагается что они создавались для того чтобы находится в поиске и приносить трафик, но из-за ошибок при формировании структуры или перелинковки получились обрывы в связке. Так что практическая ценность именно в том, чтобы искать такие обрывы (ошибки) и устранять, путем проработки структуры, или банально связывать их с другими страницами сайта. Вопрос в  теме как раз был в том, что может получиться так что клиент создал sitemap не при помощи плагина или скрипта, а при помощи онлайн генератора (по сути того же краулера), а значит в финальный отчет такие «сиротки» не попадут.

Но в принципе ответ то я по итогу получил, за что и благодарю. Просто хотел убедиться, что других способов для получения полного списка страниц нет, а значит я могу с себя снять дополнительную ответственность как аналитик 😁


vataga_a

miketomlin #:
Да, конечно.

👍


vataga_a

vataga_a #:


Антоний Казанский

vataga_a #:
Но просто хочется делать свою работу более основательнее что ли.

Основательность — она не в том, чтобы придумать себе нефункциональные задачи, а в том, чтобы приблизить свой анализ к выявлению проблемных зон и разъяснению путей решений в контексте конкретной проблемы, описанной клиентом.

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

vataga_a #:
Что касается страниц-сирот, то у меня встречаются подобные случаи, такие страницы удается находить при помощи подключения sitemap в парсинг краулером, при условии что sitemap как раз сгенерирован силами самой CMS.

Если ссылка на данную страницу генерируется движком и отображается в sitemap-е, то это уже не страница-сирота. 

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

Безусловно полезно сравнить объём индексации и фактическое кол-во сгенерированных ссылок в sitemap-е, но чаще всего это проблемы связаны с тем, что на сайте много шаблонизированных выводов и очень мало страниц с уникальным контентом, которые поисковик исключает из индекса или не индексирует.

vataga_a #:
Но в принципе ответ то я по итогу получил, за что и благодарю. Просто хотел убедиться, что других способов для получения полного списка страниц нет, а значит я могу с себя снять дополнительную ответственность как аналитик 😁

Как аналитику вам надо сразу определить пределы ваших проф. задач. Ваша задача не технические изыскания со стороны — выявить, как вдруг сторонник движок чужого сайта может сформировать страницу, которая может быть недоступна в общей навигации, а исходить из общих задач сайта и бизнеса, который обслуживает данный сайт. 

Пока я читал ваш текст, вспомнил, что в связке CMS Joomla есть интересный и довольный известный компонент SEF 404, так вот при особых настройках, он генерирует некоторое кол-во служебных страниц, которые в принципе недоступны из общей навигации. Обратиться к ним можно, зная данный компонент и определённые настройки, поэтому когда я настраивал сайты, я сразу прописывал блок редиректов, чтобы эти страницы автоматически редиректили на рабочие разделы. Вот это как раз пример страниц-сирот, описанных вами, но если об этом не знать, то о их существовании невозможно догадаться и подобрать к ним со стороны — тоже. 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *