Автоматическая проверка орфографии в 1000 карточек товаров через AI Яндекс Спеллер | Марина Погодина, PROMAREN
Яндекс Спеллер в связке с Make.com стал для меня рабочей лошадкой: за полчаса настраиваю сценарий, и проверка орфографии в 1000 карточках проходит без участия человека. По состоянию на февраль 2026 это один из самых быстрых способов навести порядок в текстах и не утонуть в ручной правке.
Обновлено: 7 февраля 2026
Время чтения: 12-14 минут
- Что такое Яндекс Спеллер в реальной работе
- Как проверять орфографию в карточках через Make.com
- Зачем вообще подключать AI к проверке текста
- Как встроить Спеллер в экосистему автоматизации
- Какие грабли ждут и как их обойти
В начале 2026 я поймала себя на знакомой картине: у клиента 1000+ карточек товаров, команда выгорела на правке описаний, а опечатки все равно всплывают в отзывах. Кофе остыл, Google Sheets подвис, а «увлажняющий крeм» продолжал жить своей жизнью.
Тут стало понятно, что проверка орфографии должна быть не задачей копирайтера, а сервисом. Спокойным таким роботом, который не спорит про запятые, а молча прогоняет все через Яндекс Спеллер и возвращает чистый текст. И да, без отдельного разработчика и недель внедрения.
Что такое Яндекс Спеллер в реальной работе
3 из 5 проектов по контенту в 2025-2026 у меня проходят через Яндекс Спеллер — и это не столько про нейросети, сколько про спокойную, предсказуемую проверку орфографии под РФ-контур.
Если по-простому, Яндекс Спеллер — это сервис Yandex, который берет текст, находит орфографические и часть грамматических ошибок и возвращает варианты исправлений. Формально это API, а по ощущениям — очень строгий корректурщик, который не спрашивает, красиво ли звучит фраза, а просто чинит «кросовки» на «кроссовки». Именно так он и работает: отправляем запрос на endpoint https://speller.yandex.net/services/lookup, указываем язык, формат текста и получаем JSON со списком найденных ошибок и подсказками.
Важный момент, который часто недооценивают: Спеллер заточен под русский язык и живет внутри экосистемы Yandex, без VPN и приключений с доступом. В начале 2025 Yandex активно развивал Yandex Neuro и YandexGPT для генерации и анализа текста, но именно Спеллер по-прежнему остается базовым инструментом чистой орфографии, особенно для e-commerce, где важны названия, характеристики и короткие описания, а не тонкие стилистические нюансы.
По данным официальной документации Yandex (справка по Спеллеру) лимит одного запроса — до 1 МБ текста, а это очень много для карточек товаров, поэтому в реальных сценариях мы упираемся скорее в лимиты Make.com, чем в сам API. Для разворота в Make достаточно HTTP-модуля, параметров запроса и минимального JSON-парсинга — никакого кода на стороне магазина. Я в PROMAREN обычно добавляю поверх еще уровень логирования, чтобы потом не гадать где у клиента сломался сценарий.
Это означает, что Спеллер — не очередной «умный» сервис, которому нужно долго объяснять контекст. Он честно и узко решает задачу: исправить явные ошибки. А вот как встроить его в цепочку из Google Sheets, маркетплейса и CRM — это уже история следующего блока, где вступает в игру Make.com и нормальная архитектура.
Как проверить орфографию в карточках через Make.com
1000 карточек за 30 минут — это не маркетинговая цифра, а обычный сценарий Make.com с 7 модулями и Яндекс Спеллером, который спокойно прожёвывает батчи по 100-150 текстов за пару секунд.
Типичная сцена в начале проекта выглядит так: у клиента свалка описаний в Google Sheets или выгрузка из 1С, в которой заголовки, подзаголовки и характеристики живут в разных колонках. Раньше это раздавали копирайтерам «на вычитку», и кто-то потом реально сидел и глазами искал «крем для ллица». Сейчас я просто считаю строки, проверяю лимиты Make.com и закладываю отдельный сценарий под проверку орфографии — один раз настроили, дальше только триггеры меняем.
Чтобы это работало стабильно, внутри Make сценарий обычно строится по одинаковой логике, которую легко адаптировать под Google Sheets, Airtable или импорт CSV с маркетплейса.
Как выглядит базовый сценарий в Make.com
В Make цепочка для проверки орфографии карточек почти всегда одна и та же: триггер на таблицу, разбиение на батчи, вызов Яндекс Спеллер, парсинг и запись назад. В PROMAREN я тестировала это на 1500 карточках косметики: запуск от Google Sheets «Watch rows», дальше Iterator режет массив на порции по 100 строк, чтобы не упираться в лимиты платформы, а HTTP модуль отправляет конкатенацию названия и описания в Спеллер. Ответ в JSON разбираем модулем Parse JSON, вытаскиваем предложенные варианты и собираем новый текст.
После этого Router делит поток: если были найдены ошибки — обновляем строку в таблице или шлем PATCH в CRM, если нет — оставляем как есть, что экономит операции. Array aggregator в конце склеивает батчи для ровной отчётности по сценарию, чтобы было понятно, сколько карточек реально изменилось. Такой сценарий на 1000 карточек в среднем пробегает за 5-10 минут, а основные 20-30 минут уходят не на работу AI, а на расстановку фильтров и тесты на первых десяти строках.
Здесь работает простое правило: чем прозрачнее сценарий, тем меньше сюрпризов на проде. Поэтому я всегда оставляю один модуль с логированием в отдельную вкладку Sheets — туда кладём исходный текст, исправленный и метку времени, чтобы через неделю можно было восстановить картину, если кто-то спросит «почему у нас поменялась формулировка».
Как упаковать 1000 карточек в запросы к Спеллеру
Сама интеграция с Яндекс Спеллер в Make упирается в две вещи: лимит размера текста и аккуратную упаковку данных. Я обычно склеиваю название и описание через разделитель (например, » || «), чтобы потом, если нужно, можно было разрезать текст обратно. В HTTP модуле задаю метод POST, адрес сервиса Спеллера и передаю текст в теле запроса или как query-параметр, в зависимости от удобства, но обязательно указываю lang=ru и format=plain или html, если в описании есть теги.
Чтобы 1000 карточек прошли без ошибок, я делю их на примерно 10 батчей по 100 строк в Iterator, а внутри уже ограничиваю текст до нескольких тысяч символов, если у клиента вдруг оказались романы вместо описаний. По опыту PROMAREN, даже на бесплатном тарифе Make с лимитом по операциям такой сценарий вытягивает 8-10 тысяч проверок в месяц, если аккуратно ставить фильтры и не обновлять строки зря. Здесь снова выручает отдельное лого-сховище — мы видим, сколько реально запросов улетело в Спеллер, а сколько карточек были «чистыми» и не трогались.
Ну и маленький нюанс: я всегда начинаю с теста на 10-20 строк, прогоняем это вместе с клиентом, чтобы не было ощущения магии. Люди должны видеть, как именно AI исправляет текст и где границы его ответственности, иначе потом все недочеты переписывают на «нейросеть сломала нам карточки». Дальше уже можно спокойно переходить к вопросу, зачем вообще подключать AI к такой проверке, если можно «посадить стажера».
Чем полезен AI для проверки текста в 2026
Сейчас подключение AI к проверке текста — это уже не история про «сделаем красиво», а про возврат 10-20% рабочего времени команды контента, особенно когда речь идет о маркетплейсах и крупных каталогах.
Когда я только переходила из аудита в автоматизацию, считала, что орфография — это то, что просто «надо делать руками». После нескольких проектов с Wildberries и Ozon-продавцами стало ясно, что руки там заканчиваются очень быстро, а тексты продолжают плодиться. AI, в том числе тот же Яндекс Спеллер и Yandex Neuro, хорошо закрывают рутину: находят и чинят повторяющиеся ошибки, подчищают описания, не устают на 800-й карточке и не спорят, где уместен разговорный стиль.
В одном из интернет-магазинов одежды мы за январь 2026 прогнали через автоматизированную проверку 5000 карточек: сначала через Спеллер, потом через легкий анализ тона описаний для A/B-тестов. Нашли около 18% текстов с ощутимыми ошибками, при этом время команды на вычитку упало с двух рабочих дней до 15 минут на запуск сценария и разбор спорных случаев. Если считать даже по 500 рублей в час, разница по месяцу получилась очень заметной, а главное — люди наконец ушли от бесконечного «подправь запятые» к нормальной работе с содержанием.
Я поняла главное: автоматизация проверки орфографии — это не про красивую технологию, а про то, чтобы людям возвращать фокус на смыслы, а не на запятые.
С точки зрения 152-ФЗ и white-data подхода PROMAREN, такая обработка данных безопасна: в Яндекс Спеллер уезжают не персональные данные, а тексты карточек, то есть нет истории с передачей ФИО или контактов. Роскомнадзор в своих материалах по персональным данным (официальный сайт) прямо указывает, что обезличенные текстовые массивы без идентификации человека не попадают под жесткие требования. Тут важно лишь не пытаться через тот же сценарий проверять, например, обращения клиентов с телефонами и адресами — для этого уже другая архитектура.
Сейчас все чаще к Спеллеру в Make я добавляю еще один слой AI: генерацию описаний через YandexGPT, а затем обязательную проверку этих же текстов через Спеллер. Так получается связка: нейросеть пишет, Спеллер подчищает, а человек смотрит только на спорные варианты и уникальные карточки. Про такие многоступенчатые сценарии я отдельно разбираю кейсы в разделе кейсы автоматизации на сайте PROMAREN и иногда показываю живые демо в канале PROMAREN.
Дальше встает вопрос не «использовать ли AI для проверки текста», а «как это встроить в общую архитектуру так, чтобы оно не жило отдельной жизнью». И вот тут подключаются другие инструменты автоматизации и общая стратегия, а не только один модуль с Яндекс Спеллер в Make.
Как встроить Спеллер в экосистему автоматизации
Один сценарий Make с Яндекс Спеллер полезен, но настоящий эффект начинается, когда проверка орфографии становится частью общего конвейера контента — от черновика до выгрузки в маркетплейс.
В 2025-2026 у меня вырисовалась типовая картина: бизнесы одновременно крутят n8n, Make.com, где-то рядом Cursor для разработки лендингов, а еще пару самописных интеграций. Если не договориться на старте, кто у нас отвечает за «чистоту текста», то легко получить три разных места, где по-разному правится описание одного и того же товара. Поэтому я всегда стараюсь сначала нарисовать архитектуру, а уже потом добавлять Спеллер в конкретные цепочки.
Вот как часто выглядит экосистема, где проверка орфографии встроена нормально, а не «пришита сбоку».
- Черновики генерируются или пишутся в Notion/Google Docs, а затем попадают в базу (Airtable, Sheets, CRM).
- Отдельный сценарий n8n или Make отвечает за обогащение: характеристики, категории, SEO-метки.
- Яндекс Спеллер встроен как промежуточный шаг перед выгрузкой на маркетплейс или сайт.
- Логи и результаты проверок складываются в отдельную таблицу для аудитора/аналитика.
- Финальный экспорт идет через единый слой интеграции с Ozon/Wildberries или CMS сайта.
Такая схема помогает избежать эффекта «поменяли описание в одном месте, а в другом забыли», потому что точка истины для текста одна, и именно там регулярно крутится Спеллер. На сайте PROMAREN я как раз описываю подход, в котором автоматизация без архитектуры — это хаос с красивым интерфейсом, и проверка орфографии тут не исключение.
Иногда имеет смысл сравнить, где логичнее запускать проверку текста — в Make.com, n8n или вообще вынести в отдельный микросервис. Для этого удобно собрать маленькую табличку с критериями, особенно когда техдир спрашивает «почему именно так».
Инструмент Где крутить Спеллер Когда удобно Make.com HTTP модуль в сценарии Быстрый no-code, маркетплейсы, Sheets n8n HTTP node + JS Свои сервера, больше контроля, логика посложнее Отдельный сервис Свой API-слой над Спеллером Большие объемы, единый доступ для всех систем
Я не зашиваю компании жестко в один инструмент: где-то в PRD-процессах сидит n8n, где-то Make.com закрывает интеграции с внешними SaaS. Главное, чтобы было одно-единственное место, где текст проходит через Спеллер перед тем как уйти пользователям. А если хочется посмотреть на живые примеры архитектур — в разделе лендинг на Cursor мы как раз показываем, как контент из AI проходит несколько фильтров, включая проверку орфографии, прежде чем попасть на сайт.
Дальше остаются самые «веселые» вопросы: какие грабли чаще всего встречаются, где ломается проверка орфографии на реальных данных и что стоит предусмотреть сразу, чтобы не переписывать сценарий с нуля через месяц после запуска 🙂
Какие грабли ждут при проверке 1000 карточек
9 из 10 сбоев в сценариях с Яндекс Спеллером происходят не из-за сервиса Yandex, а из-за мелочей в архитектуре Make.com и данных, которые мы туда честно скармливаем.
Самые частые истории начинаются одинаково: «мы все настроили по инструкции, но что-то оно работает как-то странно». Когда начинаешь разбирать логи, вылезают вполне приземленные вещи: токен внезапно истек, один из столбцов превратился в HTML-кашу, а где-то по дороге пропал идентификатор строки, и обновления улетели не туда. В начале 2026 у меня была серия таких разборов, после которых я завела себе мини-чек-лист по сценариям со Спеллером.
Типовые ошибки и риски проще всего разложить на несколько коротких правил, которые проверяю каждый раз, даже если сценарий кажется «совсем простым».
- Лимиты: следим за размером текста (до 1 МБ) и количеством операций Make, особенно на бесплатных тарифах.
- Формат: для HTML-описаний обязательно ставим format=html, иначе теги превращаются в мусор.
- Авторизация: токен Yandex лучше хранить в одном месте и иметь напоминание о его обновлении.
- Логи: отдельная таблица с исходным и исправленным текстом спасает при любых разборках.
- Тесты: сначала 10-20 карточек, только потом полный запуск на 1000+ позиций.
Один раз мы решили, что сценарий и так «достаточно простой» и можно обойтись без нормального логирования. Ха-ха Через неделю клиент пришел с вопросом, почему часть брендов внезапно поменяла регистр и пару формулировок. Хорошо, что там был бэкап таблицы, но осадочек остался, и с тех пор логи я не обсуждаю, а просто закладываю по умолчанию. Это как внутренний аудит: пока все хорошо, никому не интересно, а в момент инцидента все резко вспоминают, что хотели прозрачность.
С точки зрения методики white-data PROMAREN, я еще смотрю на то, чтобы в такие сценарии не затекали персональные данные. В текстах карточек обычно их нет, но иногда в описания могут попадать имена или контакты, особенно в услугах. В таких случаях я ставлю дополнительный фильтр или вообще развожу потоки: один для товаров, второй для того, что может содержать ПДн, и там уже другой режим обработки. Это немного замедляет запуск, зато потом не приходится объяснять, куда и какие данные мы отправляем, если вдруг придет вопрос от службы безопасности.
В итоге получается, что честная архитектура под 152-ФЗ и понятные логи важнее, чем еще одна «фича» в сценарии. А Яндекс Спеллер тут остается надежным кирпичиком: он делает свою работу, пока мы не начинаем кормить его странными данными или пытаться решить им задачи, для которых лучше подходят другие AI-инструменты. Про комбинирование с нейросетями, n8n и Cursor у меня много практики в блоге PROMAREN и в демо-версии бота, но это уже история для отдельного разбора.
Когда проверка орфографии начинает окупаться
Если отбросить технические детали, для меня в этих сценариях главное одно: в какой момент автоматизация перестает быть экспериментом и становится нормой. Как только команда перестает открывать Google Docs для вычитки карточек и вспоминает про орфографию только по уведомлению из сценария — значит, система встала на рельсы.
По опыту PROMAREN, это обычно происходит после первого полноценного запуска на 1000-2000 карточек, когда виден реальный процент исправленных ошибок, время обработки и экономия часов. Дальше уже проще обсуждать новые модули, генерацию описаний, эксперименты с тоном и A/B-тесты, потому что базовый слой — проверка орфографии через Яндекс Спеллер — тихо делает свою работу в фоновом режиме.
Обо мне. Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead. С 2024 года помогаю в РФ строить автоматизацию на n8n, Make.com, Cursor, внедряю AI-агентов. Пишу в блоге и канале.
Если хочется разобрать свою связку «маркетплейс — таблицы — AI», посмотри примеры архитектур на сайте PROMAREN и подборку «гайды по n8n» и «статьи про Cursor» в блоге. Для тех, кто любит сразу потыкать руками — есть мягкий вход через тестовый доступ к боту с автоматизацией контента.
Что ещё важно знать
Можно ли обойтись без Make.com и всё равно использовать Яндекс Спеллер?
Да, Яндекс Спеллер можно использовать и без Make.com, если у вас есть разработчик или внутренняя команда, готовая написать интеграцию напрямую к API. В таком случае вы отправляете запросы к сервису Спеллера из своего кода или микросервиса и обновляете тексты в БД или CMS. Но Make удобен тем, что позволяет собрать сценарий без кода, быстро менять логику, подключать таблицы и маркетплейсы, поэтому для теста гипотез и небольших команд он часто оказывается проще и дешевле.
Что делать, если Спеллер исправляет то, что трогать не надо?
Если Яндекс Спеллер меняет бренды или специфические термины, стоит отфильтровать их на своей стороне или настроить списки исключений. Это можно сделать через простые условия в Make или n8n, проверяя текст на наличие определённых слов и пропуская их мимо Спеллера. Ещё один вариант — сначала прогонять текст через собственный словарь брендов и технических терминов. В итоге Спеллер занимается массовыми опечатками, а важные названия остаются в исходном виде, и это сильно снижает риск неприятных сюрпризов.
Нужно ли хранить исходные тексты после автоматической проверки?
Да, хранить исходные тексты очень полезно, особенно если вы меняете массово описания или заголовки карточек. Резервная копия в отдельной таблице или базе позволяет быстро откатить неудачные правки и проанализировать, где автоматизация переусердствовала. Это дешёвая страховка: место в Google Sheets или базе стоит мало, а вот час работы команды по ручному восстановлению описаний уже заметно дороже. Поэтому я всегда закладываю такой лог-слой как часть нормальной архитектуры.
Можно ли комбинировать Яндекс Спеллер с генерацией текста в YandexGPT?
Да, и такой сценарий сейчас становится базовым: сначала YandexGPT генерирует черновик описания товара, затем этот текст автоматически уходит в Яндекс Спеллер на проверку орфографии, после чего сохраняется в таблицу или CMS. Такой конвейер удобно собирать в Make.com или n8n, добавляя фильтры и ручную проверку для сложных категорий. В итоге человек подключается только там, где нужно экспертное знание, а рутину по генерации и вычитке текста берут на себя AI-инструменты.
Как понять, что проверка орфографии уже достаточно автоматизирована?
Автоматизация проверки орфографии считается зрелой, когда команда почти не открывает документы ради вычитки и не переправляет карточки вручную. Основными сигналами становятся стабильная работа сценариев, понятные логи и редкие обращения к «ручным» правкам, только для сложных случаев. Если любые новые карточки естественно попадают в сценарий с Яндекс Спеллер, а люди воспринимают это как стандартный этап процесса, значит система встроена в рабочий контур. Всё остальное — просто эксперименты и разовые автоматизации.