![\"Человек](\"данные/картинки/pressfeed-03-oblozhka.jpg\")
18px. В теле статьи ноль h2/h3, ноль strong, ноль ul/ol. Значит текст надо оформлять прямо в их редакторе после вставки. ПРОВЕРЕНО 10.09.2026 повторно: правка в редакторе работает и сохраняется. После неё в статье 10 заголовков h3, 18 выделений жирным и 2 списка на 8 пунктов. Заголовки площадка ставит уровнем h3, h2 у неё занят служебными блоками", "ПРОВЕРЕНО 10.09.2026: alt у иллюстраций площадка переписывает на «Изображение N для статьи ...». Свои описания в alt не сохраняются, писать смысл в alt бесполезно", "ПРОВЕРЕНО 10.09.2026: схемы 1600x900 площадка уменьшает до 1024x576, показывает на 650 px. Обложка приводится к 650x365" ] }, "чеклист": [ { "что": "Ссылка на портал в тексте", "готово": false }, { "что": "Заголовок совпадает с тем, что в плане", "готово": true }, { "что": "Текст написан и лежит в заводе", "готово": true }, { "что": "alt у каждой картинки", "готово": true }, { "что": "Дисклеймер про доход и окупаемость, если в тексте есть такие цифры", "готово": false } ], "письмо": null, "размещение": [ { "поле": "Рубрика", "значение": "«Блоги» - автору доступна только она" } ], "анонс": null, "текст_html": "
Третий материал для «Журнала Pressfeed». Первые два: как я заводил 13 площадок за две недели и как площадки формулируют отказы. Этот - про методику: три ошибки скрипта, каждая из которых завышала цифры в мою пользу. Почему без ссылки на портал. Журнал про PR и медиа, ссылка на собственный сайт в тексте о методике читается как реклама. Тот же принцип, что в первых двух материалах. Проверка своих правил: длинных тире нет, женского рода нет, названий компаний нет, у каждой цифры дата замера.\n
Контент-анализ конкурентов обычно выглядит так: берём список сайтов, пишем скрипт, который ищет нужные слова, получаем проценты. Дальше проценты идут в презентацию, в статью или в стратегию.
\nЯ делаю такие разборы для своих материалов и вчера расширил выборку с 15 сайтов до 94. Заодно добавил новые признаки. Первая же выгрузка дала красивые цифры, и почти каждая из них оказалась завышенной.
\nРассказываю, где именно скрипт соврал, потому что ошибки эти не мои личные, а типовые: они возникают в любой разметке по словам.
\nЯ считал, сколько сайтов прямо гарантируют доход. Скрипт искал корень «гарант» рядом с деньгами. Получилось 32 из 94.
\nПошёл смотреть цитаты и нашёл вот что:
\nпро поставки;
\nНи один из этих случаев не является гарантией дохода, ради которой затевался подсчёт. Слово одно, смысл разный.
\nЭта тише и опаснее. На нескольких страницах скрипт нашёл «гарантию» там, где стояло ровно обратное:
\nЭто оговорки, то самое, чего на большинстве страниц как раз не хватает. А в моей таблице они пополнили колонку «гарантируют доход». То есть признак считал в свою пользу дважды: и когда обещание было, и когда его специально снимали.
\nПосле того как отрицания отсеклись, а ложные срабатывания я снял руками, осталось 14 сайтов из 94 вместо 32. Цифра упала более чем вдвое.
\nТретий признак считал, называют ли на сайте срок поддержки после открытия: «сопровождение 12 месяцев», «обучение 5 дней». Скрипт искал слово о поддержке и число с единицей времени в пределах 90 знаков.
\nДевяносто знаков равны примерно полтора предложения, и в них попадает много лишнего. Например, номер пункта в списке: «7. Открытие» стояло рядом со словом «сопровождение», и страница засчитывалась как назвавшая срок.
\nЯ сузил окно до сорока знаков и потребовал, чтобы число стояло вплотную к слову. Было 35 сайтов из 94, стало 17.
\n![\"Схема](\"данные/картинки/pressfeed-03-oshibki.jpg\")
Три правки, и три цифры из моего разбора изменились вдвое. Если бы я опубликовал первую выгрузку, читатель получил бы завышенные проценты, а я бы об этом не узнал: итоги выглядели правдоподобно.
\nПравдоподобность остаётся главной ловушкой автоматической разметки. Скрипт не ошибается случайно, он ошибается систематически и в одну сторону. Слово находится чаще, чем встречается смысл, поэтому почти всегда завышается именно то, что вы хотели показать.
\nПорядок, к которому я пришёл:
\n1. Смотреть цитаты, а не итоги. Скрипт должен сохранять фрагмент текста вокруг каждого срабатывания. Без этого проверить нечего. 2. Читать глазами по десять примеров на признак. Не все, но достаточно, чтобы увидеть системную ошибку. Три моих нашлись именно так. 3. Отдельно искать отрицания. «Не гарантирует», «не является», «без учёта»: проверьте каждый признак на то, что будет, если рядом стоит отрицание. 4. Считать окно в знаках, а не на глаз. Чем шире окно, тем больше ложных совпадений, и растут они незаметно. 5. Вести файл ручных правок. У меня это отдельный список: страница, признак, цитата, причина. Он же объясняет расхождение между автоматической выгрузкой и итогом, если кто-то спросит. 6. Публиковать границы выборки рядом с цифрами. Откуда взялись адреса, сколько отсеяно, что именно считается признаком.
\nЕсли разбор делает подрядчик или нейросеть, спрашивайте не проценты, а три вещи: как звучало правило, сколько случаев проверено руками и что именно поправлено. Ответ «скрипт посчитал» означает, что цифры никто не видел.
\nМой замер, о котором речь, сделан 22 сентября 2026 года: 94 посадочные страницы, адреса из живой поисковой выдачи, тринадцать случаев поправлено вручную. Выборка не случайная, и я пишу это рядом с каждой цифрой.
", "есть_текст": true }