Сюда буду собирать самое важное из crawl budget. Без рекламы и инфоцыганщины

Сюда буду собирать самое важное из crawl budget. Без рекламы и инфоцыганщины

Канал открыт. Здесь будут разборы и наблюдения по теме «crawl budget»

Канал об одном: crawl budget. Без сторонних тем

Готовлю первый разбор. Подписывайтесь — выйдет на этой неделе

**Matomo Websites** — это не «список сайтов», а модель данных для нормальной архитектуры аналитики.

Внутри обычно 3 сущности:
- `Website` — отдельный проект/домен
- `Mobile App` — приложение, не сайт
- `Roll-Up` — агрегация нескольких проектов в один слой отчётности

Схема простая:
`domain-a.com` + `domain-b.com` + app = `Roll-Up: brand`

Что важно для technical SEO и аналитики:
1. **Не смешивать разные бизнес-юниты в один Website**
2. **Roll-Up делать только для верхнего уровня**, иначе ломается сегментация
3. **Сразу проектировать иерархию**: бренд → продукт → домен → среда (`prod/stage`)

Типовая ошибка при масштабировании: завести 50 сайтов «как получится», а потом пытаться чинить отчёты через фильтры. Это не архитектура, это долг.

Практика:
- отдельный Website на каждый публичный домен
- отдельный проект на staging
- Roll-Up для общего P&L и executive dashboards
- единые naming convention и доступы

Если Matomo растёт без схемы — дальше будет не аналитика, а зоопарк отчётов 🧱

ИИ в конструкторах сайтов уже не «вау», а набор отдельных автоматизаций. И это важно: **он не делает сайт сам**, он закрывает куски пайплайна.

Что реально работает:
- `copy + layout` для лендингов и MVP
- генерация мета\-тегов, alt, FAQ
- шаблонные секции под типовые страницы
- быстрый черновик структуры под семантику

Что пока в основном маркетинг:
- «сделай мне готовый сайт под бизнес» без ручной доработки
- сложная логика, где нужен нормальный dev\-контроль
- SEO без проверки: ИИ легко генерит мусор в тайтлах, дублях и внутренних ссылках

Схема простая:

`бриф -> ИИ черновик -> ручная правка -> техпроверка -> релиз`

Если убрать последний шаг, получаем не productivе tool, а генератор проблем для crawl budget и индексации.
Вывод: ИИ уже полезен как ускоритель, но не как замена техспецификации, QA и SEO\-ревью. 🔧

**ИИ как сборочный цех для сайтов.**
Не для «сделай красиво», а для задачи: быстро поднять 2 проекта без дизайнера и верстальщика.

Что важно технически:

`Claude Code` взял на себя:
- генерацию страниц с нуля
- перенос с Tilda в управляемую структуру
- админку, чтобы контент не правился руками в коде

По факту это уже не «чатик пишет текст», а связка, где LLM работает как __scaffold generator__: каркас, компоненты, правки, повторный прогон.

Проблема, как обычно, не в коде, а в итерациях.
`100+` правок уровня «выше / ниже / ещё выше» — это не магия, а стоимость отсутствия нормального ТЗ и визуальных ограничений.

**Вывод для SEO/tech-команды:**
если у вас типовой контентный сайт, ИИ может ускорить запуск.
Если нужна предсказуемость, контроль индексации, шаблоны, админка и возможность быстро менять структуру — это уже рабочий инструмент.

Но проверка всё равно нужна:
- `robots.txt`
- sitemap
- SSR/рендер
- статус коды
- логика URL и шаблонов

ИИ не снимает техдолг. Он просто собирает его быстрее.

**Server Actions для inline CRUD в Next.js** — это не «ещё один способ отправить форму». Это способ убрать лишний API-слой между UI и записью.

Что ломается в ручной схеме:
`route handler -> fetch -> pending/error/success -> синхронизация UI -> закрытие/очистка формы`

На одном create/edit/delete это терпимо. На экране с несколькими inline-формами начинается зоопарк: отдельные обработчики, дублирование состояний, гонки между `Enter`, `Escape`, `blur`.

С Server Actions цикл короче:
`form -> action -> FormData -> сервер -> типизированное состояние -> UI`

Ключевой паттерн в Next.js App Router:
`state + formAction + isPending`

Почему это важно для technical SEO/продуктовых интерфейсов:
- меньше клиентской обвязки
- предсказуемый write-path
- проще поддерживать несколько CRUD-операций в одном экране
- меньше шансов сломать UX при ошибке или повторной отправке

Если у вас inline rename/delete/create в админке или CMS — смотрите не на «красоту API», а на количество промежуточных слоёв. Чем их меньше, тем меньше точек отказа.

—
Кто про алгоритмы пишет регулярно — @InterviewLabPro

**CSR ломают чаще, чем TLS**

Проблема обычно не в выпуске сертификата, а в том, что в `CSR` уже заложили мину: забыли `SAN`, неправильно собрали wildcard, руками ошиблись в `openssl.cnf`.

Схема простая:

`CN` → почти мёртвый параметр
`SAN` → реальный список хостов
`wildcard` → покрывает только один уровень, не `a.b.example.com`

Если в `CSR` нет всех нужных имён, CA выдаст сертификат ровно под этот набор. Потом начинается классика: `www` живёт, `api` падает, `staging` забыли, а прод ловит `NET::ERR_CERT_COMMON_NAME_INVALID`.

Почему это становится критично: срок жизни сертификатов режут до **47 дней к 2029**. Ручной выпуск с правками в `openssl.cnf` и чеканием SAN после факта — уже не процесс, а лотерея.

Что нужно вместо ручного режима:
- генерация `CSR` из шаблона
- автоподстановка `SAN`
- валидация wildcard до отправки
- выпуск через ACME/автоматизацию, а не через «потом поправим»

Вывод: если `CSR` не проверяется машиной, ошибка уедет в прод вместе с сертификатом.

Голое `invalid_request` — это не ошибка. Это отказ в коммуникации.

Если разработчик в 02:00 получает пустой ответ без:
- что сломалось,
- где именно,
- как исправить,

то у вас не API, а генератор тикетов в поддержку.

Что нужно в нормальном error contract:
1. **Стабильный код** — машина должна понимать класс ошибки.
2. **Человеческое сообщение** — коротко и без канцелярита.
3. **Подробность для дебага** — поле, параметр, ожидаемый формат, correlation_id.
4. **Предсказуемая схема** — чтобы клиент не парсил текст regex’ом.

RFC 9457 — это хороший ориентир: ошибка должна быть объектом, а не одной строкой. Для DX это критично. Потому что метрика онбординга не “красиво ли выглядит Swagger”, а **time to first successful request**. Если первый вызов занимает 40 минут вместо 4, вы теряете не только разработчика, но и доверие команды.

Признак сильного API: он скучный.
Никаких сюрпризов, никаких “ну тут надо догадаться”.
Только жесткий контракт, понятные ошибки и минимум ночных сеансов шаманства. 🔧

Kafka consumer и retry — место, где легко словить дубли и сломать семантику обработки.

Схема простая: consumer читает сообщение, делает side effect, потом падает до commit offset. Kafka считает сообщение необработанным и отдаёт его снова. В итоге:
- запись в БД может выполниться дважды;
- внешний API получит повторный запрос;
- метрики «успешной обработки» врут.

Это не баг Kafka. Это следствие модели at-least-once. Если нужен exactly-once, его не «включают галочкой»: надо проектировать идемпотентность, транзакции и границы побочных эффектов.

Что проверять:
1. Когда делается commit offset — до side effect или после.
2. Есть ли дедупликация по message key / event id.
3. Как устроен retry: синхронный, через DLQ, отдельный topic.
4. Что будет при rebalance: consumer может прочитать то же сообщение повторно.

Практический вывод: если операция не идемпотентна, retry = риск двойного действия. В проде это надо подтверждать логами и трассировкой, а не надеждой на «и так прокатит» ⚙️

Race Condition — это не «редкий баг», а ошибка синхронизации на уровне обработки запросов.

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

Три базовых типа:
1) time-of-check/time-of-use — проверили одно состояние, использовали уже другое;
2) конкуренция за ресурс — два запроса пишут в одну сущность без блокировки;
3) гонка на бизнес-логике — уязвимость появляется не в БД, а в последовательности действий.

Что важно: это не лечится «добавить задержку». Нужны атомарные операции, блокировки, idempotency key, транзакции, корректная сериализация критичных запросов.

Если в системе есть деньги, лимиты, роли или одноразовые действия — race condition надо проверять руками и нагрузкой. Иначе найдёте его не вы, а атакующий.

WooCommerce для разработчика — это не “плагин для магазина”, а слой абстракции поверх WP, где SEO часто ломается на уровне шаблонов, фильтров и индексации.

Что обычно проверяют первым:
— как формируются canonical на карточках, категориях и пагинации;
— не плодит ли тема дубли через фильтры, сортировки и UTM;
— как грузятся JS-блоки: не прячут ли контент и внутренние ссылки до hydration;
— что попадает в sitemap: товары, категории, атрибуты, вариации;
— как ведут себя robots и noindex на страницах поиска, фильтров и корзины.

Если WooCommerce собран криво, Google тратит crawl budget на мусорные URL, а не на товарные страницы.
Если собран нормально — получаете предсказуемую архитектуру индексации, меньше дублей и меньше сюрпризов в логах.

Минимальный чек перед релизом:
1) выгрузить список URL из sitemap;
2) сравнить с логами бота за 7–14 дней;
3) проверить, какие страницы реально получают обход;
4) найти дубли по параметрам;
5) убедиться, что важные категории не закрыты случайным noindex ⚙️

AI в IT — не магия, а рычаг на FTE.

С конца 2024 у консультантов чаще приходят не CTO, а CEO и CFO с простым запросом: «штат раздут, надо резать». И да, это уже не слухи. На рынке нормализуется сценарий, где от команды ждут не +10% продуктивности, а -30% headcount. У некоторых — до 70–80%.

Что это значит для CTO:
1) Не «внедрить ИИ», а пересобрать контур работ.
2) Не автоматизировать хаос, а сначала выкинуть лишние процессы.
3) Не мерить эффект ощущениями — только цифрами: throughput, cycle time, cost per delivery.

ИИ сам по себе людей не заменяет. Он убирает рутину, ускоряет ревью, генерацию, triage, документацию. Но если у вас нет стандарта задач и метрик, результат будет один: шум вместо экономии 🤖

Ключевой сдвиг: CTO должен быть не объектом сокращений, а инициатором архитектуры новой команды. Иначе решение примут без него.