И снова об индексации большого раздела сайта (много букв)

Вы, наверное, гуманитарий по жизни, ведь так?

Я практик на потоке. А в данном случае мне неясна суть ваших затруднений. Вот объём сайта. Вот среднее число страниц краулинга. Вот логи. Чего вам не хватает для решения задачи, и в чём суть этой задачи?

Хорошо. 

У меня затруднений особых нет.

Просто вы налегке даёте ТС совет (цитирую) - "Проверяйте также лимит сканирования."

Меня заинтересовало как Вы его определяете и я начал задавать наводящие вопросы, надеясь, что ответы будут интересны не только мне, но и другим читателям. Далее последовало: - "В Search Console  - среднее число просканированных за день. Берем число страниц, которые должны быть в индексе. Делим на среднее число сканированных за день. По итогам смотрим: если результат в 10 раз больше просканированных за день, то кричим караул и бегаем кругами. Меньше трёх - хороший результат, можно не париться."
Точных цифр никто не даст. Да их и нет, в этой сфере они все динамические, поэтому надо отталкиваться от медианных данных. И в этом плане градация 3/10 работает хорошо. Большой сайт? - Ну, используйте поправочный коэффициент. "

Так вот - объём сайта (в страницах) делённый на среднее число страниц в день даст только количество дней, необходимых для сканирования данного сайта. Ничего более. Это же элементарная алгебра с соблюдением размерностей. Ни а каком вычислении лимита сканирования (сначала надо определиться что это и в какой размерности вычисляется) по Вашей формуле идти речь не может. Ни с поправочными коэффициентами ни без (кстати непонятно из каких соображений выбирается так называемый поправочный коэффициент и его величина).

Вы и своим клиентам так налегке втюхиваете речи с вкраплениями технических словосочетаний типа "поправочный коэффициент", "среднее число страниц краулинга", "надо отталкиваться от медианных данных", "в этом плане градация 3/10 работает хорошо", в надежде или с уверенностью, что клиент не перепроверит элементарные вещи?

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

Только без обид, каждый зарабатывает как может.

Вы хорошо понимаете, что такое лимит сканирования? Или ждёте чудес от статистических данных?
Я вижу в вашей писанине какие-то придирки с непонятной мотивацией. Если вам надо выявить проблемы со сканированием сайта - вы используете эти данные. Они полезны, они работают.
Как просчитать поправочный коэффициент - это уже ваша аналитика. Можете исходить от среднего объёма сайтов в интернете, в своём сегменте, а дальше опираться на собственную статистику по сайтам в целом.
Техника работает, если, конечно, вам нужны результаты. Можете искать свою - это SEO, канонов нет, всё - на имеющихся данных и на опыте. Делаете гипотезу, тестируете. Работает - берем на вооружение. Что там вы хотите перепроверять? Данные сёрч консоли?

Хотелось бы услышать Вашу версию.

Опять же - без обид. Что бы разъяснить и себе и тем, кто нас будет читать, что вкладываем в смысл одного и того же термина.

Хорошо, давайте уточним и обобщим.
Лимит сканирования (он же - краулинговый бюджет) - это несколько устаревший термин, обозначающий сейчас скорее объём вычислительных ресурсов, выделяемых нейросетью гугла для сканирования сайта в прямой связи с его техническим состоянием, ценностью для пользователей с точки зрения нейросети, цитируемостью и т.д. и т.п.
Точных цифр тут быть не может, вы можете лишь опираться на некие усредненные показатели, а в качестве необходимого инструмента прибегать к инсайтам. Всё, что у вас есть - это данные Google Search Console, Google Analytics и данные логов по визитам гуглоботов.
Из этого жиденького набора вы можете извлечь какие-то выводы и построить какие-то гипотезы, способные помочь улучшить сканирование сайта и перераспределить цели этих визитов. Вот у вас данные по визитам из панели вебмастера, вот данные из логов по целевым URL, среди которых могут доминировать папки шаблона, давно несуществующие URL (например, после переноса сайта пару лет назад), либо нецелевые URL, получающие статус важных в глазах гуглобота на основе пользовательских сигналов.
Всё остальное - вилами по воде. Для примера: по утверждениям Мюллера, гуглобот может ждать отклика сервера 2 минуты (при рекомендуемой норме - 0,2-0,5с). Будет ли он ждать столько в реале? - Другой вопрос. То же самое с редиректами. насколько я помню, 10 считается допустимой нормой. Однако на практике гуглобот вполне себе прекращает переходы где-нибудь на пятом переходе.
Вся градация реально укладывается в "хорошо обходит - плохо обходит". Разброс 3-10 позволяет работать с этой градацией чуть тоньше, не более того.
Знаете подход получше - поделитесь, с удовольствием почитаю.

Ну, вот видите, что то начинает выкристаллизовываться.

Сейчас Вы утверждаете, что лимит сканирования - это несколько устаревший термин с безрамерной величиной, хотя ещё в 9:30 утверждали (цитирую) - "Среднее количество просканированных страниц - это и есть условный лимит сканирования. ".

Для меня он разделяется на 2 базовые величины:

1. Лимит по времени (ибо ни кто не любит долго ждать) и тут я довожу время отклика до <100ms для пиковой нагрузки. В полупиковой (рабочий режим) 40-50мс. Идеал для меня, над которым еще работаю - 20мс.
2. Лимит по дисковому объёму. Ибо весь этот шлак хранится физически на дисках (даже с учётом эффективной упаковки, хешей, контрольных сумм и т.д. и т.п.). А диски, как известно не резиновые. По-этому я лично минимизирую верстку и всякий левый хлам в коде. Опять же идеал для меня 10кБ, пока топчусь на 15-25кБ.
   

Времена меняются. То, что бот зашёл на сайт - ещё не значит, что он будет парсить контент. Или весь контент, а не один какой-то важный (для него) абзац или другой фрагмент. Мы этого не знаем, и всё, что у нас есть - это а) данные консоли; б) логи. То есть количество урлов, страницы в индексе в сопоставлении с тем, что там должно быть, плюс какая-то динамика по сканированию конкретных папок.

В консоли фиксируются только странички, там не понять, что бот старательно перебирал js и прочие служебные файлы. А это - тоже часть лимита.
Стало быть, говорить исключительно о лимите сканирования - не совсем корректно. Но других терминов пока нет.

насколько я смотрел индекс - там лежит ВЕСЬ код страницы на дату/время последнего обхода с кодом последнего обхода 200 от начального <doctype> до конечного </html> и даже все заголовки сервера. По этому и не только - от левых js-ов стараюсь избавляться.

Т.е. бот забирает ВСЮ страницу (если дождётся её, конечно).

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

По крайней мере у моих сайтов - так.

Дайте определение "бот зашёл на сайт".

А если бы вы парсилку писали, то по каким признакам выделяли бы в коде "важный абзац/фрагмент"? Может у вас даже есть примеры, когда из двух изменённых абзацев после скачивания ботом (html-документа) только один абзац учёлся? (вопрос не про рисуемое js) Вы не можете это проверить?.. «мы этого не знаем»

Вы для кого это пишете? Для верующих клиентов? Им 'нейросеть гугла' крышу сносит?