Google ужесточает модерацию финансовой вертикали

Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …

➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali

🧠 Ещё больше инсайтов → в канале AFF.top

7 ошибок в RU CMS-проектах, которые тихо ломают сайт после запуска

После запуска проекта проблемы обычно не в «кривом дизайне», а в базовой сборке. На 1С-Битрикс и MODX это видно особенно быстро: всё работает, пока не начинается контент, обновления и правки от разных людей.

— Дублирование логики в шаблоне и в компоненте. Когда часть условий живёт в верстке, а часть — в PHP, правки превращаются в лотерею.
— Хардкод путей, ID и текстов. Один перенос раздела — и уже ищут, почему слетели ссылки или баннеры.
— Нет нормального разделения: вывод, бизнес-логика и служебные проверки смешаны в одном файле. Это убивает поддержку.
— Игнорирование кеша и тяжелых запросов. Сначала «не мешает», потом сайт тормозит на обычных страницах.
— Редактирование прямо в шаблонах без документации. Через месяц никто не помнит, где именно менять блок.

Отдельная боль — права доступа и админка. Если редактор видит лишнее или не видит нужное, проект быстро превращается в ручной режим с ошибками.

Хорошая CMS-сборка — это когда следующий разработчик понимает проект без археологии по репозиторию.

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

Contentful — когда нужен управляемый контент, а не очередной WordPress с плагинами

Contentful удобен там, где контентом управляют не разработчики, а редакция: модель данных строится из отдельных блоков, а API отдаёт их в любой фронтенд. Для SEO-проектов это значит одно: можно собирать шаблоны страниц под каталоги, обзоры, FAQ и pSEO без ручной верстки каждой публикации.

Что внутри:
— контент-модели с полями, связями и локализацией;
— GraphQL и REST для интеграции с сайтом, приложением, витриной;
— роли и права для редакторов, авторов, модераторов;
— превью-поток, чтобы проверять страницу до публикации.

Где он работает:
— контент-хабы и медиа;
— многоязычные сайты;
— проекты, где одна сущность переиспользуется в десятках шаблонов.

Где режет ногу:
— если вам нужен “просто блог” без разработки;
— если команда не умеет думать сущностями и начинает лепить всё в один rich text;
— если не настроить валидацию и превью, редакция быстро сломает структуру.

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

Не тащите туда текст как в WordPress. Сначала сущности, потом шаблоны, потом редакторский процесс.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

🧠 Ещё больше инсайтов → в канале AFF.top

Контент-инфраструктура ломается не от CMS, а от мелких решений в модели и сборке

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

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

Третье — сборка и публикация. Если каждый апдейт гоняет весь сайт, проект быстро становится неповоротливым. Лучше иметь инкрементальную публикацию, очереди задач и отдельный слой для превью, чтобы редактор видел результат до выката. Это особенно важно там, где контент меняется пачками.

Если коротко: хорошая контент-инфраструктура — это когда редакция не воюет с моделью, а SEO-команда не чинит одно и то же вручную каждую неделю.

Page builders убивают скорость не сами по себе — их чаще роняют 5 типовых ошибок

Если лендинг на Elementor, Bricks или другом билдере внезапно стал тяжёлым, проблема обычно не в самом конструкторе, а в сборке страниц. Смотрите на базу: один DOM без мусора, минимум вложенных контейнеров, отсутствие дублирующихся блоков и единый подход к сетке.

— Не ставьте виджет ради одной строки текста: лишний блок = лишний wrapper, CSS и JS.
— Не смешивайте 3 системы отступов сразу: глобальные стили, настройки темы и ручные margin/padding.
— Не тащите на каждую страницу тяжёлые слайдеры, иконки, анимации и фоновые видео.
— Не игнорируйте шрифты: 4 начертания и 2 семейства часто дороже, чем кажется.

Есть наблюдение которое стоит проверить: половина «тормозов» лечится не заменой билдера, а пересборкой шаблона под повторное использование. Хедер, hero, карточки, CTA — если они вынесены в глобальные шаблоны, вы меньше плодите уникальный HTML и проще держите Core Web Vitals.

Фиксируйте правило: сначала структура и контент, потом эффекты. На коммерческих WP-проектах это почти всегда даёт больше, чем попытка «ускорить» уже раздутую страницу плагином-кэшем.

Monorepo ломается не от размера, а от слабых границ между пакетами

За неделю в репах обычно видно одно и то же: когда shared-код тащат куда попало, монорепа начинает тормозить не в CI, а в голове команды. Держите правило: каждый пакет должен иметь одну ответственность и понятный публичный API.

• Не импортируйте внутренности соседнего пакета через deep import. Если нужен файл изнутри — значит, граница выбрана плохо.
• Разделяйте build, test и lint на уровне workspace, а не одного корня. Иначе любая мелочь триггерит лишнюю работу.
• Для зависимостей используйте явные версии и lockfile, а не «и так сойдёт» через hoist.
• Следите за path alias: удобный алиас в tsconfig не должен прятать реальную структуру проекта.

Есть наблюдение которое стоит проверить: monorepo помогает только там, где пакеты реально переиспользуются. Если код не делится между приложениями, вы платите за сложность управления без выигрыша в build time и bundle size.

Хорошая монорепа выглядит скучно: мало магии, много договорённостей, быстрый CI и предсказуемые импорты.

Astro для контентных проектов: когда он экономит время, а когда начинает мешать

Astro хорошо заходит там, где большая часть сайта — это контент, лендинги, документация, SEO-страницы и немного интерактива. Его сильная сторона — сборка страниц из островков: всё статично по умолчанию, а JS подключается только туда, где он реально нужен.

Есть три типовые ошибки при старте:
— тащить в Astro тяжёлые клиентские острова «на всякий случай»;
— делать слишком много интерактива на одной странице;
— забывать, что скорость сайта ломают не только скрипты, но и картинки, шрифты, сторонние виджеты.

Если нужен каталог, блог, маркетинговый сайт или docs — Astro часто даёт более простой путь, чем полноценный SPA. Но если у вас сложный личный кабинет, постоянные переходы без перезагрузки и много состояния между экранами, архитектура начнёт спорить с задачей.

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

Если сомневаетесь — задайте один вопрос: сколько интерактива реально нужно пользователю на первом экране? Именно от ответа зависит, будет ли Astro ускорителем или лишним слоем.

Контент-инфраструктура ломается не в CMS, а на стыке моделей, API и шаблонов

Если у вас плывут pSEO-страницы, виновата часто не сама headless CMS, а то, как вы собрали контур вокруг неё.

• Модель данных должна отвечать на один вопрос: как это будет рендериться и индексироваться. Если поле нельзя использовать в шаблоне, навигации или фильтре — оно, скорее всего, лишнее.

• API должен отдавать ровно те связи, которые нужны фронту и генератору страниц. Когда контент приходится собирать на клиенте из пяти запросов, вы сами создаёте лаги, битые блоки и лишнюю сложность.

• Шаблоны лучше строить от типов страниц, а не от “универсального компонента на всё”. Для SEO-проектов это обычно заканчивается мусорной версткой и одинаковыми сниппетами на сотнях URL.

• Права доступа, предпросмотр, публикация и переиндексация должны быть частью процесса, а не ручным ритуалом редактора. Иначе контент живёт отдельно, а сайт — отдельно.

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

Sanity хорош, пока у вас контент — это не таблица, а набор связанных сущностей

У Sanity сильная сторона не в «красивой админке», а в документной модели: можно хранить статьи, авторов, блоки, категории, варианты заголовков и связи между ними без борьбы с rigid-schema. Для pSEO это удобно, когда нужно собирать страницы из повторяемых модулей: интро, FAQ, сравнение, CTA, локальные вставки.

Что внутри: GROQ даёт гибкие выборки, редакторам нравится быстрый live preview, а schema легко подстроить под контент-команду. Но за свободу платишь дисциплиной: если не продумать блоки, ссылки и обязательные поля, редактор начнёт плодить мусор, а фронт — десятки исключений.

Где Sanity работает лучше всего:
— обзорники с кучей однотипных страниц;
— медиа, где часто меняется структура статьи;
— pSEO-проекты, где важны переиспользуемые блоки и быстрые правки.

Где режет ногу: сложные права доступа, слишком вольные схемы без контент-архитектора и попытка превратить всё в «просто CMS». Sanity не спасает от плохой модели данных; он только быстрее показывает, где она сломана.

Если берёте Sanity под SEO-проект, сначала рисуйте контентные сущности и связи, а уже потом дизайн админки. Иначе получите удобный редактор для неудобной структуры.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

🧠 Ещё больше инсайтов → в канале AFF.top

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

🧠 Ещё больше инсайтов → в канале AFF.top

React Server Actions ломают архитектуру, если смешать их с клиентским состоянием

За неделю в репах чаще всего виден один и тот же перекос: action вызывают как «умный fetch», а потом тащат в неё валидацию, мутирующий UI и бизнес-логику одним комом. В итоге граница между сервером и клиентом исчезает, а отладка превращается в поиск побочного эффекта.

Держите простое правило:
— action должна принимать данные формы, проверять их и менять серверное состояние;
— всё, что влияет на интерфейс до ответа, оставляйте в клиенте;
— результат action возвращайте в компактном виде: успех, ошибка, новый id, а не целый экран данных.

Есть наблюдение которое стоит проверить: чем меньше логики в action, тем проще переживать повторные вызовы, отмены, прогревы и деградацию сети. Особенно это заметно в SaaS, где одна форма может работать в десятке сценариев, а не в одном happy path. Здесь server action — не место для «магии», а узкий вход в доменную операцию.

Если action начала читать cookies, трогать внешние API и менять несколько таблиц, проверьте: не пора ли вынести orchestration в отдельный service-слой, а action оставить тонкой обёрткой. Так код переживает и рост продукта, и замену UI без переписывания половины формы.

Headless CMS для SEO-фермы ломается не в API, а в модели контента

Если сделать контент-модель как в блоге на WordPress, headless быстро превращается в дорогой статический сайт с красивой админкой. Для SEO-проектов важны не «страницы вообще», а шаблоны, которые массово собираются из данных.

Рабочая схема такая:
— отдельные сущности под кластеры, города, бренды, категории, FAQ, сравнения;
— у каждой сущности свои поля, а не один универсальный текстовый блок;
— связки между сущностями через relation, а не ручные ссылки в редакторе;
— SEO-поля вынесены отдельно: title, description, canonical, robots, schema.

Главная ошибка — смешивать редакторский контент и генеративный контент в одной корзине. Тогда невозможно нормально масштабировать pSEO: редактор начинает ломать структуру, а разработчик — чинить исключения вместо системы.

Второй частый провал — отсутствие правил для пустых и частично заполненных страниц. В headless нужно заранее решить:
— что показываем, если нет FAQ;
— как рендерим карточку без изображения;
— какие блоки обязательны для индексации;
— где ставим noindex, а где добираем страницу внутренней перелинковкой.

Если модель данных не позволяет собрать 1000 однотипных страниц без ручной правки, это не headless-архитектура, а просто CMS с API.

Начинайте не с фронта, а с карты сущностей и SEO-полей. Именно там обычно экономится месяц работы и ломается половина будущих проблем.

Strapi хорош для SEO-фермы, пока не начинаете лепить контент-модель как в WordPress

Strapi — нормальный выбор для медиа и pSEO, если с самого начала разделить сущности: шаблон страницы, источник данных, блоки контента, мета-теги. Тогда редактор добавляет карточки, категории и локации без участия разработчика, а фронт сам собирает тысячи страниц из одной схемы.

Что обычно ломает проект:
— все поля складывают в один тип «Страница»;
— slug, title и description живут руками в каждом документе;
— фильтры и связи не продуманы, и потом API начинает страдать от лишних запросов;
— права доступа дают слишком широко, и контент-команда случайно правит не то.
Strapi это прощает до первого роста, а потом начинается ручная археология по базе.

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

Главное правило: сначала рисуете карту контента, потом уже собираете модели. Иначе headless превращается в склад полей, а не в систему публикации.

Контент-инфраструктура ломается не в CMS — а между шаблоном, API и SEO

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

Для pSEO и обзорников полезно думать не страницами, а типами контента:
— сущности: бренд, категория, город, интент, оффер;
— связки: «бренд + категория», «город + услуга», «сравнение + фильтр»;
— системные поля: title, description, H1, slug, canonical, noindex, schema.

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

Нормальная инфраструктура держится на трёх правилах:
— контент редактируется в CMS;
— правила сборки живут отдельно в коде;
— SEO-валидация проходит до публикации, а не после индексации.

Ещё один частый провал — отсутствие маршрутизации на уровне модели. Если slug и иерархия не продуманы заранее, потом трудно сделать чистые URL, редиректы и пересборку разделов без мусора в индексе.

Если коротко: строьте не «сайт на CMS», а систему, где контент, шаблон и SEO-правила не мешают друг другу. Это экономит больше, чем любая миграция.

Astro удобно брать не за “магический SSG”, а за границы между контентом и интерактивом

У него сильная сторона не в том, что он “умеет всё”, а в том, что он заставляет явно разделять: что рендерится статикой, а что должно ожить на клиенте. Для контентных сайтов, лендингов, документаций и маркетинговых витрин это часто важнее, чем один большой SPA-каркас.

Есть три проверки перед стартом:
— 80% страницы должно жить без JS;
— интерактивные острова должны быть маленькими и редкими;
— данные для сборки должны приходить из одного предсказуемого слоя, а не из пяти API подряд.

Если проект начинает расти, первым ломается не Astro, а дисциплина вокруг него: вставляют тяжелые виджеты в каждый блок, тянут клиентский код на весь экран и превращают страницу в обычный SPA с лишними накладными расходами. В этот момент выигрыша от островной архитектуры уже не видно.

Хорошая привычка: сначала собрать страницу как статический документ, потом точечно добавить формы, фильтры, поиск и счётчики. Всё, что не требует мгновенной реакции пользователя, лучше оставлять на сервере или в билде.

Если нужен сайт, который быстро грузится, легко индексируется и не разваливается от лишнего JS, начинайте с Astro как с системы границ, а не как с очередного фреймворка для всего сразу.

Алиса AI будет конкурировать с Google AI Studio

Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…

➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio

🧠 Ещё больше инсайтов → в канале AFF.top

В Zennoposter добавили ИИ-помощник

Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…

➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik

🧠 Ещё больше инсайтов → в канале AFF.top