кэш
meta тэги
Ни в кеше, ни в мета тегах этих данные не хранятся.
Данные для Last Modified и <lastmod> берут из базы данных (если конечно этот механизм реализован).
p.s. У большинства современных CMS этот механизм уже реализован.
В коде ответа сервера (если LM поддерживается и корректно настроен).
Смотреть через Вебмастер, можно также через bertal.ru
Данные о последнем изменении страницы могут храниться в секции <lastmod> в XML карте сайта.
Идея в принципе проста.
1) Добавляем список проксей.
2) Определяем лимит полученных URL-ов (поле, куда можно ввести численное значение, например, 500).
3) Определяем режим обхода при котором при достижении указанного лимита URL-ов, происходит пауза и дальше досбор данных происходим уже со следующего прокси.
Наглядно примерно так:
прокси1 -> URLs: 1-500
прокси2 -> URls: 501-1000
прокси3 -> URls: 1001-1500
и т.д.
В Яндексе по этому вопросу писали, уточняли почему If-Modified-Since не шлет? Получили подтверждение от Яндекса, что не работает?
Или у вас не получилось и вы для себя решили, что не работает?
Спасибо, да это надо сделать давно...
Реализация Last-Modified в связке c If-Modified-Since имеет смысл когда у вас более 10 тыс. страниц и на сотнях из них идут активные обновления. Это актуально для действительно больших интернет магазинов и крупных СМИ.
Однако, несмотря на скепсис Mik Foxi поддержку работы Last-Modified действительно стоит реализовать на любом интернет ресурсе и кроме данных заголовка сервера дату последних изменений страницы также важно корректно передавать в секцию <lastmod> XML карты сайта. Это влияет на приоритизацию индексации, что безусловно важно.
Попробую максималку скорости еще раз, врядли мощностей хватит, не просто так минимум ставил.
Вы конечно можете экспериментировать со скоростью обхода (если сервер жалуется), но исходя из вашего стартового вопроса - на позиции это не повлияет.
Вечер добрый, покуда вы как автор напомнили про SiteAnalyzer.
Cкажите пожалуйста, а в вашей программе планируется использование динамической смены прокси в одном рабочем цикле?
Тюнинг robots.txt? Это мило 😊
И вот какой вопрос у меня: не понимаю, стоит или не стоит закрывать от индексации поисковиками профили игроков (примерно такого вида: ht tps://ww w.mafia syndi cate.ru/Ga mer/3986 - уберите пробелы).
Это не дубли, не пустые страницы с одной стороны, с другой стороны чем они пригодятся поисковикам - особо непонятно.
Каких-то чётких гайдов не нашёл, поэтому если у кого есть рекомендации по тому, как сделать выбор - приму с благодарностью.
Закрыть индексацию профилей без компромиссов. Во-первых, выше Дмитрий правильно сказал - это всегда маяк для притяжения спамеров. Если вы ресурсно даёте возможность использовать страницы своего сайта для ссылок - этим будут пользоваться.
Далее, надо ещё помнить о том, что не все пользователи хотели бы, чтобы через поиск находили их игровые профили. Со временем наверняка с этим столкнетесь.
Итого - не создавайте условий для будущих проблем, превентивно решайте этот вопрос.
Запрет к индексации и без компромиссов,
(вспомнилось вдруг - привет фанатам видеосалонов из 90-х) 😊
Regta, моё почтение, приятно когда на форум заглядывает кто-то из "старичков" 😎 🤝
Уже не на одном хостинге (виртуальном) наблюдаю. При попытке сканировать большие сайты (от 10 тысяч страниц и больше) - происходит следующее:
сканирование практически полностью останавливает (если и продолжается - то в час по чайной ложке и 50/50 с "No Response"). на сайт с браузера зайти уже не могу - пишет "Превышено время ожидания"
После остановки сканирования - примерно через 30-40 минут доступ к сайту через браузер восстанавливается.
Что это???
Именно так это происходит во время временной, либо постоянной блокировки IP со стороны сервера (нередко со стороны CDN сервиса).
Либо полный блок и FROG в процессе просто замирает и с текущего IP невозможно зайти на сайт (проверку проще всего организовать через TOR), либо временный - при превышении числа обращений к сайту, временная блокировка, которая со временем автоматически снимается.
Какое самое очевидное решение - снизить лимит нагрузки при парсинге, возможно вам удастся "проскочить" систему блокировки, напоминаю это здесь
Бывает и такое. Если это общие настройки шаред хостинга, то они просто игнорируют и говорят, у нас всё нормально, но на самом деле просто не собираются решать подобные "узкие вопросы", говорят - переходите на выделенный сервер, там для клиентов могут быть другие условия. Ну а если вы не клиент, то вообще присылают шаблонные ответы суть которых - становитесь клиентом, оплачивайте услуги и потом будем разговаривать про ваши хотелки.
Вопросы:
- сталкивались с подобным? Кто хостинг-провайдер?
Я в последние 2 года по клиентским анализам сталкиваюсь частенько. Крайний раз - буквально на прошлой неделе, CDN сервис блокировал, я написал клиенту с просьбой проверить, он передал мою просьбу админку и админ подтвердил, - ответил, ваш IP автоматически забанен - переносим его в список доверенных IP.
После этого действия Frog беспрепятственно всё спарсил.
Увы, принять политику хостинга и попытаться подстроиться. Frog как ни крути создаёт множественные параллельные (если число потоков несколько) и последовательные запросы к серверу и сервис хостинга в зависимости от своей политики может их блокировать - это их право определять порядок доступа.
По ситуации. Если вы арендуете выделенный хостинг и вам запрещают для работы подобный доступ к сайту - искать хостинг, где ваш IP внесут в список доверенных IP. Это, пожалуй, самый универсальный вариант.
Если всё равно банят (или договориться не удалось), а ситуации такие бывают, то я предпочитаю не работать с таким сайтом/клиентом. Я вообще последние несколько лет стараюсь не загонять себя в угол и не работать с проблемными клиентами, которые не хотят решать вопросы, не хотят вникать в процесс, не понимают, что современное продвижение - это путь технических и организационных преобразований, как сайта, так и бизнеса - словом, не работать с теми, кто не хочет, не может, не будет, не понимает - не созрел до того, чтобы решать текущие проблемы на качество ином уровне.
Однако, если расширять видение вопроса, то могут быть следующие варианты:
1) Как уже сказал выше попытаться изменить скорость запросов к серверу.
2) Вспомнить про то, что Frog даёт возможность изменить User-Agent и можно представиться, например, Гуглом,
в ряде случае это тоже помогает. Также там есть возможность кастомных настроек.
3) Если у хостинга есть ограничение на кол-во последовательных запросов, то можно рассмотреть варианты динамической смены IP в рабочем цикле парсинга.
- точно знаю, что есть сервисы, которые по времени, либо по команде обеспечивают смену IP на лету (такие предложения довольно частое явление у селлеров мобильных прокси);
- есть услуги VPN сервисов, которые делают это в вашем ручном управлении (условно говоря, вы устанавливаете клиент VPN на свой компьютер) и примерно на глаз через каждые 900 страниц ставите Frog на паузу и на горячую меняете переподключение к другому VPN серверу с другим IP - ожимаете паузу и продолжаете дальше собирать.
4) Добавлю еще возможности парсинга сторонними уже специализированными инструментами. Это уже конечно не про Frog вообще, но в ряде случае актуализирует некоторые важные задачи. Здесь я бы обратил внимание конечно на Зенку (Zennoposter), потому как по себя можно самостоятельно писать полноценные алгоритмы обработки данных. И A-Parser.
Для наглядности - в Зенке вы пишите шаблон или скрипт для парстинга рабочих данных, покупаете в районе 1000 рублей несколько сотен шарен IP-шников (которые вы будете использовать не только для этих целей) и формируете рабочий цикл, где автоматически меняете IP-шники.
Так, что коллега, пробуйте, но в принципе, когда что-то намеренно блокируется и не решается, то я уже морально не берусь за такие задачи. Хотя всегда существует спортивный интерес перебороть ситуацию, тут уж выбирайте, что вам ближе 😉
Скорость обхода влияет на результаты индексирования.
Это всё равно, что спросить - влияет ли скорость пешехода, идущего на работу, на качественные результаты его работы.
Как минимум ошибаетесь в том, что поддомены - это для Яндекса отдельные сайты и поисковые квоты (которые как раз раз коррелируют со скоростью обхода) у поддоменов разные.
Универсальный совет - поставьте ПС самой определять скорость индексации. Если хостинг не ругается на избыточную нагрузку от поисковых роботов от Яндекса, то вручную регулировать этот показатель нет необходимости.
Без компромиссов - над.
Например? Соц. сеть/комьюнити?
p.s. Ну а если глобально то перемены конечно уже подходят и вот-вот придут, про web 3.0 интересно расписано здесь (прямую ссылку давать не буду - так как уже банили на этом форуме с не понятной пометкой):
vc.ru/future/331769-chto-za-web-3-0-o-kotorom-vse-govoryat-i-kakie-nedostatki-nyneshnego-interneta-on-nameren-ispravit
Почитайте - походу туда все и движемся.
Прочитал, занятно, но пока воспринимаю как утопическую иллюзию.
Мировые корпорации, создающие технологии и системы управления не допустят потери власти и контроля (они десятилетиями над этим работали), поэтому описанная там утопическая децентрализация на мой взгляд может быть востребована лишь небольшой частью специализированных сообществ, но в массовое использование им хода не дадут, ибо на самом общем уровне "это не отвечает государственным интересам".
