![\"\"](\"https:\/\/alexeyit.ru\/pictures\/bunker.png\")
\n<\/div>\nПосмотрим, что будет дальше. Вполне возможно, что однажды мы здесь не услышимся, поэтому чтобы не теряться — буду дублировать тексты в max (https:\/\/max.ru\/id352831751730_biz<\/a><\/a>).<\/p>\n Если честно, не понимаю негативный шлейф вокруг max. В целом кажется, что ребята активно и быстро накидывают функционал, по крайней мере десктопное приложение обновляется буквально через день. Касательно вбросов про то, что следят, смотрят, читают - мне кажется это больше вбросы, потому что по цифровому следу вас и так при желании найдут<\/strong>. И вопрос в других мессенджерах этого нет? Не думаю. Скорее вопрос в том, кто именно читает, а не читают ли вообще<\/strong>. Ну да ладно, сегодня не об этом. Ну а если мучает паранойя — можно завести отдельное устройство с симкой и без микрофона и камеры.<\/p>\n Сейчас идет много новостей о том, что ВПН «умирают», их старательно вычищают из сторов для Android и iOS. Операторы связи вбрасывают новости о том, что трафик через VPN будут дополнительно тарифицировать, и прочие вещи, призванные закрутить гайки и ограничить доступ к нежелательным ресурсам.<\/p>\n В целом я думаю, что да, доступность сервисов уже снижается<\/strong>, но полностью запретить ВПН не смогут. Ведь существует огромное количество сервисов, которым этот инструмент просто необходим для безопасности. Почти на любом крупном проекте доступы в боевую среду идут только через ВПН, используются удаленные рабочие столы и закрытые сети. То есть да, часть самых популярных протоколов будут ограничивать<\/strong>, но технология останется как таковая, потому что она нужна для работы большого числа компаний, в том числе и в госсекторе.<\/p>\n Есть классические решения вроде OpenVPN он массовый и поэтому хорошо определяется через DPI и часто режется. WireGuard — более современный и быстрый, но тоже уже научились детектить по поведению трафика. Старые корпоративные вещи типа IPSec часто живут, потому что их используют в инфраструктуре компаний. Вся эта история крутится вокруг DPI — провайдеры анализируют трафик, сигнатуры и поведение соединений.<\/p>\n Вторая мысль — про зарубежный трафик. Обрубить его полностью можно, но это будет очень больно для многих проектов. Ведь любой портал, сайт или интернет-магазин с большой долей вероятности тянет из внешнего мира библиотеки, скрипты, шрифты и другие зависимости, сервера которых находятся за пределами страны. Да, это можно поправить, но не быстро и не дешево.<\/p>\n Но что делать с обновлениями тех же Windows? Или с сервисами вроде Google Docs и таблиц? Их инфраструктура тоже находится за рубежом. Полное отключение такого трафика ударит уже не по пользователям, а по бизнесу и процессам<\/strong>.<\/p>\n Поэтому глобально железный купол над интернетом вряд ли появится<\/strong>. Скорее это будет похоже на сачек — отфильтруют то, что на поверхности и используется большинством. Но те, кому это действительно нужно, все равно найдут способы<\/strong>, благо их в интернете более чем достаточно.<\/p>\n",
"date_published": "2026-04-02T14:39:17+03:00",
"date_modified": "2026-04-02T14:39:08+03:00",
"tags": [
"Инструменты и сервисы",
"Личный опыт и размышления"
],
"image": "https:\/\/alexeyit.ru\/pictures\/bunker.png",
"_date_published_rfc2822": "Thu, 02 Apr 2026 14:39:17 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "141",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/bunker.png"
]
}
},
{
"id": "132",
"url": "https:\/\/alexeyit.ru\/all\/chto-takoe-llms-txt-zachem-nuzhen-fayl-llms-txt-i-pochemu-on-ne\/",
"title": "Что такое LLMS.TXT: зачем нужен файл llms.txt и почему он не работает на практике",
"content_html": " Ранее я уже писал, что трафик от LLM растёт<\/strong> пока в основном в англоязычном сегменте, но и в зоне .ru они давно и активно индексируют сайты<\/strong>. И, что заметно, в некоторых нишах от туда есть исходящий трафик<\/strong>.<\/p>\n Но есть и обратная сторона. Банить IP разных ботов руками плохая идея, хоть и реализуемая через WAG. На этом фоне идея «как-то управлять ИИ-ботами»<\/strong> выглядит абсолютно логичной. Так и наткнулись на llms.txt<\/strong> файл, который подают как аналог robots<\/strong>.txt, но не для поисковиков, а для ботов<\/strong>, обучающих нейросети. Мол, можно аккуратно подсказать, какие страницы важные и что именно стоит читать. Если упростить, llms.txt это markdown-файл со списком ссылок и краткими описаниями контента<\/strong>. По ощущениям, это что-то вроде sitemap.xml «для ИИ»<\/strong>, только с претензией на новый стандарт. Проблема в том, что: Показателен комментарий Джона Мюллера из Google<\/strong>. По смыслу он сравнил llms.txt с meta-тегом keywords<\/strong>: формально вы можете что-то там написать, но реальные системы этим просто не пользуются<\/strong>. Если нужно понять, о чём сайт, проще и надёжнее прочитать сам сайт<\/strong>, а не верить декларациям владельца.<\/p>\n Это подтверждается и практикой. В одном из обсуждений на Reddit ребята анализировали серверные логи порядка тысячи доменов<\/strong> и выяснили, что llms.txt почти никто не запрашивает<\/strong>. Его могут забирать какие-то нишевые аналитические боты, но крупные AI-платформы нет<\/strong>. Откуда вообще взялась эта идея? При этом реальные задачи в AI-индексации лежат совсем в другой плоскости<\/strong>. Не текст<\/strong> с ним как раз всё более-менее хорошо. Настоящая боль визуальный контент<\/strong>: картинки без нормальных описаний, видео без расшифровок, отсутствие связи между текстом и визуалом. Именно здесь сейчас находится «слепое пятно» для большинства AI-систем<\/strong>, и именно туда логично было бы вкладывать усилия, если говорить о будущем AI-SEO.<\/p>\n Итого:<\/strong> на текущий момент более оптимального решения, чем WAF, мы не нашли<\/strong>. В существующих реализациях это почти единственный рабочий способ уберечь прод-сервер от наплыва AI-ботов<\/strong>: контроль частоты запросов, фильтрация паттернов и защита на уровне инфраструктуры, а не вера в декларативные файлы.<\/p>\n",
"date_published": "2025-12-16T17:12:39+03:00",
"date_modified": "2025-12-16T17:12:32+03:00",
"tags": [
"Инструменты и сервисы",
"Личный опыт и размышления"
],
"image": "https:\/\/alexeyit.ru\/pictures\/mis.png",
"_date_published_rfc2822": "Tue, 16 Dec 2025 17:12:39 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "132",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/mis.png"
]
}
},
{
"id": "127",
"url": "https:\/\/alexeyit.ru\/all\/pochemu-klassicheskiy-reprayser-dlya-ozon-i-wildberries-uzhe-ne\/",
"title": "Почему классический репрайсер для Ozon и Wildberries уже не работает — и что мы строим вместо него",
"content_html": " Продолжаю делиться нашим приключением в продуктовой вселенной. За это время провёл около двадцати интервью с бизнесом и людьми, которые так или иначе связаны с маркетплейсами: от продуктовых специалистов до руководителей направлений МП. Хотел понять простую вещь — кто и как управляет ценами, где автоматизация действительно работает, а где все по-старинке.<\/p>\n И выводы получились неоднозначные. В SaaS-сегменте проблема, ради которой всё затевали, почти отсутствует, вроде. Возможно, идти туда — ошибка. Но мы всё равно проверим — иногда истинная боль прячется глубже.<\/p>\n А вот в enterprise-историях проблема подтверждается. Каждый решает её по-своему, костылями и полуавтоматом. У селлеров с небольшим ассортиментом всё проще — там хватает существующих сервисов. Я насчитал больше двадцати живых решений, и у каждого свои особенности: ограничение на количество товаров, странные тарифы и отсутствие нормальных интеграций. Всё руками, о связке с 1С или динамическими ценами часто даже не мечтают.<\/p>\n На фоне всех этих находок стало понятно, что классическое слово «репрайсер» давно умерло. Актуальность была пару лет назад, сегодня это звучит как термин из музейной витрины. Поэтому решили честно обновить концепцию. Теперь это омниканальная платформа мониторинга, анализа и управления ценами<\/strong>.<\/p>\n Так получается точнее и честнее отражать то, что мы реально делаем — и то, чего нет у конкурентов.<\/p>\n Перезапустили сайт решения. Хотелось собрать всё на Тильде, но пошли другим путём — сделали максимально примитивно, чтобы проверить конверсию самого подхода. Личного кабинета пока нет, но рассчитываем довести его до ума за ближайшие одну–три недели.<\/p>\n Параллельно запустили новые стратегии. Пришлось собрать новую схему работы с ценой: учитывать маржу, доставку, бонусы, акции — всё, что влияет на финальный результат.<\/p>\n Личный кабинет стал чуть красивее обычного орчида, но ещё не тот результат, от которого отваливается челюсть, но в целом окей. Зато сделали авторизацию через email и OTP — СМС подключим позже.<\/p>\n Нашли хак на Ozon. Если товар стоит в акции, менять цену нельзя — она пишется, но берётся медианная. Однако если сначала вынуть товар из акции, обновить цену и вернуть обратно — всё работает. Абсолютно легально, пока.<\/p>\n Построили внутреннюю систему ротации прокси, чтобы они не выгорали пачками. Она следит за состоянием, и если какой-то прокси сгорает, летит алерт, что нужно пополнить запас.<\/p>\n Добавили альтернативный источник данных — из личного кабинета маркетплейсов. Точность ниже, но скорость выше. Правда, не для всех товаров.<\/p>\n По мелочам — навели порядок в настройках, закрыли баги, подтянули инфраструктурные детали.<\/p>\n В ближайшее время запускаем рекламу. Начнём с Директа — понятно, что это не самый эффективный канал для нашего типа продукта, но нам нужно проверить прямой спрос, экономику клика и набрать людей на первичный кастдев. Вероятнее всего, этот канал приведёт селлеров с небольшим оборотом — и возможно, у них просто нет проблемы. Это тоже нужно подтвердить или опровергнуть.<\/p>\n Параллельно будем выходить в аутрич через Telegram, чтобы дотянуться до среднего и крупного сегмента. Тут уже интереснее — посмотрим, что получится.<\/p>\n В разговоры с экспертами добавился новый блок — прикидка трендов. Что будет дальше?<\/p>\n API может стать платным. Больно, но не смертельно. Цена персонализируется до безумия — непонятно, что будет с РРЦ и МРЦ. Запрет на изменение цен по API? Сомнительно, но и на это у нас есть запасной вариант.<\/p>\n Далее по плану. <\/p>\n Запускаем SaaS. Недавно на YouTube наткнулся на видео про цепи Маркова. Объяснение было бодрым, простым и в отличие от универа — даже понятным. В институте эту тему нам давали сухо: формулы, матрицы переходов, вероятности. Тогда я не мог до конца понять, зачем это всё. <\/p>\n Так что же это за зверь такой — цепи Маркова?<\/strong><\/p>\n Если коротко, это способ описать последовательность событий, где каждое следующее зависит от предыдущего<\/strong>. Не от всего, что было до этого, а только от последнего шага. Пример: если человек посмотрел кроссовки, то с вероятностью 60% он кликнет на носки, а если уже на носках — то скорее всего добавит их в корзину. Вот и вся магия.<\/p>\n Сама концепция цепей Маркова родилась в 1906 году — и, что любопытно, началась она со спора. Павел Некрасов, монархист и профессор, утверждал, что закон больших чисел работает только для независимых событий<\/strong> — вроде бросков монеты. А вот социалист Андрей Марков с этим не согласился.<\/p>\n Суть спора была в том, распространяется ли закон больших чисел на зависимые события<\/strong> — когда каждое следующее испытание связано с предыдущим. И Марков не просто поспорил — он это доказал<\/strong>. Так появилась идея, что можно описывать последовательности, где каждый шаг зависит от предыдущего, но всё равно подчиняется вероятностным закономерностям.<\/p>\n История, кстати, куда интереснее, чем кажется. Если будет настроение — найди видео про этот спор, там и математика, и характеры, и немного идеологии.<\/p>\n Рекомендации и ценообразование <\/strong> Поведение покупателей на скидках — тоже цепочка. Применять этот подход можно в самых разных местах, не только в рекомендациях и ценообразовании. Например, для анализа логов и поведения систем. Когда что-то идёт не так — запрос падает, очередь зависает, сервис отвечает с задержкой — важно не просто увидеть ошибку, а понять, как она возникла. Если собрать последовательности событий и рассчитать вероятность переходов между ними, можно увидеть закономерности. По сути, это та же цепь Маркова, только вместо покупателя у нас процесс, а вместо корзины — сбой в логах.<\/p>\n Например, алгоритм PageRank от Google можно рассматривать как модель цепи Маркова: каждую страницу можно считать состоянием, а переходы между страницами — вероятностями переходов в цепи. <\/p>\n Такие модели хорошо ложатся на предиктивную аналитику: прогнозирование нагрузки, отказов, пиков активности. На этом принципе построены многие инструменты мониторинга — они не просто ловят инциденты, а предсказывают, где “цепь может порваться”.<\/p>\n И если смотреть шире — весь современный искусственный интеллект вырос из этой идеи. Марковские цепи стали базой для языковых моделей, генераторов речи, автозавершения текста. Любая нейросеть сегодня в том или ином виде опирается на вероятностные переходы между состояниями. Просто теперь этих состояний миллиарды, и они учатся не на монетах, а на петабайтах данных.<\/p>\n В итоге, цепи Маркова — это не про математику ради математики. Недавно пробежала новость: WB снова урезал часть данных<\/strong>, и у половины аналитических систем парсеры просто легли. Наш — работает как часы.<\/p>\n А буквально вечером появилась ещё одна — Ozon снова повышает тарифы<\/strong>. Кажется, не в последний раз. Так что продукт, цель которого — сэкономить продавцам и увеличить их долю прибыли на маркетплейсах<\/strong>, пока выглядит чертовски своевременным.<\/p>\n Правильный продуктовый путь по гайдам нам по-прежнему не ведом. Мы идём своим маршрутом, через ошибки и эксперименты. И раз уж на сайте пока нет журнала изменений, буду вести его здесь — в блоге.<\/p>\n С момента прошлого апдейта у нас многое поменялось. Напомню, речь идёт о GuardPrice<\/strong> — сервисе, цель которого управлять ценами на маркетплейсах по разным стратегиям<\/strong>, ориентируясь на собственные цены продавца и реальные цены, которые видит конечный покупатель.<\/p>\n Коробочная Enterprise-версия<\/strong> обросла популярными стратегиями вроде «следования за конкурентом», «удержания позиции» и так далее. Но главное — мы окончательно ударились головой и решили делать полноценный SaaS-сервис<\/strong>.<\/p>\n С подписками, тарифами, личным кабинетом — как и положено. Первый релиз уже совсем близко, и, конечно, не без приключений.<\/p>\n Так как GuardPrice изначально гибкий<\/strong> и умеет работать с любым API для обратной загрузки цен, мы решили не ограничиваться только Ozon и Wildberries. В список подключений входят Яндекс.Маркет, Ламода, М.Видео-Эльдорадо, Аптека.ру<\/strong>, и фактически можно прикрутить любой другой e-commerce<\/strong>, где есть API.<\/p>\n Есть и отдельный профиль — «стратегия парсинга». Он просто собирает цены без обратной выгрузки. Зачем? Всё просто: можно указать любую ссылку на товар, задать, где находится блок с ценой, и сервис сам соберёт данные. Очень удобно, когда нужно быстро оценить рынок или конкурентов<\/strong>.<\/p>\n Самая интересная часть — получение реальных цен, которые видит покупатель<\/strong>. В начале мы сжигали прокси буквально за сутки: вчера работают, сегодня уже бан. Теперь у нас построена полноценная балансировка нагрузки<\/strong>, где каждый поток живёт по расписанию. Мы ротируем прокси по группам<\/strong>, проверяем «живость» перед каждым заходом и автоматически выкидываем подозрительные адреса из пула. Так что теперь не выжигаем IP, не теряем данные и не вылетаем в баны<\/strong>.<\/p>\n Кстати, неожиданное открытие — бан может быть временным<\/strong>. Некоторые прокси действительно «оживают» через сутки-двое. Теперь это тоже учитываем при ротации.<\/p>\n Из ближайших задач — улучшить интерфейс<\/strong>. Сейчас он функционален, но выглядит как технический кабинет администратора. Хотим сделать понятнее, аккуратнее и ближе к продукту уровня «из коробки». <\/p>\n Параллельно готовим новые стратегии<\/strong> и полноценный аналитический блок<\/strong>. Было бы странно не использовать тот объём данных, который мы уже накопили и агрегировали.<\/p>\n Скоро первый релиз. Когда мы только стартовали, у нас была почти наивная миссия — спасать интернет. <\/p>\n Мы смотрели на сайты крупных компаний, где от SEO нет и следа, и думали: «Ну неужели так сложно сделать всё по уму?». Тогда нам казалось, что мы можем что-то изменить. Добавить смысла, структурности, системной пользы в хаос из недоработанных сайтов, мы думали что это готовые клиенты. Прошли годы, и стали понятны причины почему так получается и почему это норма. Мы стали прагматичнее, но наивность не умерла окончательно.<\/p>\n Изначально этот пост планировался как серия из 4 — 5 постов про SEO, но решил собрать один лонгрид, высказаться так сказать и закрыть тему. <\/p>\n Сегодня рекламных инструментов стало откровенно мало. Google Ads ушёл, таргет умирает, Яндекс Директ на грани pay-to-win. Из реального трафика остались Яндекс, органика Google, да блогеры. . А значит, SEO остаётся едва ли не ключевым каналом, где вы можете привлекать клиентов системно, без ежемесячных вливаний в рекламу.<\/strong> Особенно если ваш сайт — это не просто визитка, а обладает каталогом. В этом случае игнорировать SEO — всё равно что стрелять себе в ногу.<\/p>\n Когда компания запускают проекты за несколько миллионов и не может выделить хотя бы бюджет на «печеньки» для SEO <\/strong>— чтобы сайт хотя бы технически соответствовал реалиям требований поиска в 2025 года — это либо чей то хитрый план или чей то недосмотр. Говорить про зоны ответственности вероятно не стоит, так как с одной стороны это ответственность pm со стороны заказчика — знать что он покупает. С другой стороны, что за подрядчик, если профессионал не сказал об этом клиенту. Иногда компаний \/ отделов несколько, иногда это разные подразделения. Ну вы поняли. <\/p>\n SEO в текущих реалиях это не «где-то там», не только про конкуренцию с маркетплейсами. Даже случайный пресс-релиз, если он правильно залетит в органику, может привести реальный трафик, подписчиков и продажи. Но почему то это до сих пор не делается, для меня загадка. <\/p>\n Если вы работаете с SEO-подрядчиками, фрилансером, вы точно сталкивались с задачами типа: «Сделайте вёрстку валидной»<\/strong>. Мы, как разработчики, получаем такие задачи регулярно. И каждый раз у меня начинает дергаться глаз и гореть пукан<\/strong>.<\/p>\n Чтобы добиться валидной верстки на старых проектах с историей и своей архитектурой это десятки, а иногда сотни часов<\/strong> работы. А самое забавное — чаще всего такие задачи даже не обсуждаются и не обосновываются, просто «падают» в бэклог. Зачем? <\/strong>Потому что SEO-команда выгрузила 10 000 ошибок по валидатору<\/strong>. Красиво выглядит в отчёте. Звучит страшно. В голове клиента возникает ощущение: «если столько ошибок — точно надо чинить».<\/strong><\/p>\n Но давайте честно: что именно даст эта правка? Ни один SEO-специалист не скажет, что валидная вёрстка — ключ к ТОПу<\/strong>. Это один из сотен факторов<\/strong> ранжирования, и далеко не самый важный. У него просто минимальный вес при прочих равных. Потратить N<\/strong> часов разработчика на устранение «лишнего div-а» или «не тот порядок meta-тегов»<\/strong>, при этом не имея нормальных посадочных страниц и семантики — это прямое вредительство. Особенно в проектах, где нет даже базового SEO-фундамента.<\/p>\n Чаще всего они возникают из-за того, что SEO-подрядчику нужно что-то показать клиенту. Работа застопорилась, идей нет, семантика собрана, тексты поменяны, а результатов нет. Тогда в ход идут автоматические сканеры сайта: Labrika, Serpstat, Netpeak, кто что любит. Все они умеют пугать. Особенно блоком «технические ошибки».<\/p>\n Выглядит это как: «На сайте обнаружено 11 304 ошибки в разметке. Срочно устранить!<\/strong>» Это называется работа ради работы. Показная активность. И она съедает часы, ресурсы и внимание.<\/p>\n Но есть и другой сценарий. И он, честно, пугает больше. Когда SEO нет совсем. Представьте себе: проект на кастомной разработке, работает, живёт, развивается, в него вкладывают ресурсы. Мы видим это постоянно — особенно в fashion-сегменте, в ритейле, в нишевых b2b-порталах. Проекту несколько лет, десятки тысяч SKU, работает команда, маркетинг, CRM, а SEO — просто не занимались.<\/p>\n Проверяешь мета-теги: «Название раздела – Название компании»<\/strong>. Всё, и это в лучшем случае. Ни одного коммерческого запроса. Ни слова «купить», ни «в наличии», ни цен. Description — машинный или отсутствует. Хочется спросить: Почему, это же так просто? <\/p>\n Обычно в такой ситуации либо подрядчик за SEO не отвечает, либо SEO «внутри», но никто особо не вникает. Проблема в том, что даже базовые вещи — не сделаны. Хотя внедрить их стоит недорого, а отдача может быть колоссальной. 80\/20 работает и здесь, иногда. Даже не нужно пробиваться в топ по суперчастотникам, да и вероятно это сделать будет тяжело. Среднечастотные и низкочастотные запросы — абсолютно рабочая зона. <\/p>\n В e-commerce и B2B трафик идёт из двух зон: разделы каталога и карточки товара<\/strong>. По нашим данным — около 70%<\/strong> органики приходит с категорий\/разделов, остальное — с товарных страниц. При этом схема простая: один ключ — одна страница. Хочешь трафик по «синие строительные каски» — сделай страницу именно под этот запрос. Полноценную посадочную с текстом, мета-тегами и заголовками.<\/p>\n Это настолько базовая вещь<\/strong>, что удивительно, сколько проектов её игнорируют. Упрощенная структура унаследованная из 1С, объединённые категории, не оптимизированные шаблоны разделов — и вот вы сами забираете у себя органику.<\/p>\n Второй слой<\/strong> — это страницы, которые не очевидны, но часто конвертируют: поиск по сайту, фильтры, бренды в связке с категориями.<\/strong> Страницы поиска — золото. Люди вводят туда конкретные потребности: «чёрные ботинки 42 размер». Почему бы не отдать им релевантную страницу и не открыть её для индексации? Технически это просто, а эффект может быть ощутимым.<\/p>\n С фильтрами — тоже всё понятно. Например, «недорогие красные карандаши» или «премиальные зелёные маркеры». Частотка там невысокая, но именно на таких хвостах можно собирать стабильный трафик. Сделать это можно через модульную генерацию или вручную — кому как удобнее.<\/p>\n Бренды с категориями — наша любимая история. Люди ищут «Erich Krause карандаши», «Nike футболки», «Bosch перфораторы». Но на сайтах чаще всего есть только страница бренда — и всё. И пользователь тонет в хаосе товаров. Мы же рекомендуем сделать полноценные страницы по связке «бренд + категория». Это потребует генерации, возможно, сложной логики. Но оно того стоит.<\/strong> Даже если из сотни новых страниц в топ выйдут 20 — этого хватит, чтобы трафик начал расти.<\/p>\n Благо что инструментов, модулей для подобных задач хоть отабавляй. <\/p>\n Еще один кейс — когда SEO «ведут», но задач по технике \/ доработкам нет<\/strong>. Нет новых страниц, нет изменений в структуре, нет изменений по коду. Заказчику кажется, что всё под контролем — есть подрядчик, приходят отчёты. А если копнуть — там либо закупка поведенческих факторов, либо имитация активности. Да, может быть временный всплеск. Но на длинной дистанции побеждает тот, кто строит структуру, пишет контент и создает страницы под спрос. То есть без технических доработок развивать ресурс по SEO едва ли возможно. <\/p>\n Яндекс в своей справке всё давно описал: один ключ = одна страница, уникальный текст, быстро открывается. Если ежемесячный отчет не содержит блок связанный с предложениями об улучшениях и доработка — повод задуматься, на мой взгляд. <\/p>\n В целом, это справедливо и для платного трафика — там же A\/B-тесты, гипотезы и постоянные эксперименты, так что изменений, по идее, должно быть ещё больше.<\/p>\n Вложитесь туда, что реально дает эффект: в структуру, в контент, в скорость, в семантику. Создавайте страницы, которые закрывают реальные запросы. Не бойтесь автоматизации — генерация под фильтры, бренды, поиск может дать кратный рост. И если кто-то снова придёт к вам с задачей «починить вёрстку», просто спросите: «Сколько трафика это нам даст?» Если ответ — «неизвестно», возможно, стоит еще раз подумать. <\/p>\n Советы конечно звучат как за все хорошее, против всего плохого. И кажется что последнее время описанного в тексте стало меньше, но периодически все еще встречается. И это наверное хорошо. <\/p>\n <\/p>\n",
"date_published": "2025-07-23T11:57:37+03:00",
"date_modified": "2025-07-23T12:47:59+03:00",
"tags": [
"Инструменты и сервисы",
"Личный опыт и размышления",
"Технологии и разработка"
],
"image": "https:\/\/alexeyit.ru\/pictures\/SEO.png",
"_date_published_rfc2822": "Wed, 23 Jul 2025 11:57:37 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "95",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/SEO.png"
]
}
},
{
"id": "65",
"url": "https:\/\/alexeyit.ru\/all\/vhodom-v-proekt\/",
"title": "Что нужно знать перед входом в проект: вопросы для нового подрядчика",
"content_html": " Что важно узнать перед входом в новый проект клиента?<\/p>\n Или с другой стороны: что нужно держать в голове, если вы — клиент и задумались сменить подрядчика? Погнали.<\/p>\n Почти любая смена подрядчика и\/или команды на IT-проекте — это боль. Дорого, долго и зачастую с кучей неожиданностей и нюансов. Если мы заходим в такой проект, стараемся выяснить ключевые вещи — и в идеале делаем это ещё на этапе пресейла. Так и оценка будет адекватной, и отношения крепче.<\/p>\n Что случилось с предыдущим подрядчиком?<\/strong> Доступы к проекту и админке<\/strong> Что на серверах?<\/strong> Есть ли документация?<\/strong> Кто принимает решения?<\/strong> История проекта<\/strong> Какие у проекта цели?<\/strong> Как всё устроено внутри?<\/strong> Клиент вовлечён или просто «отдал и забыл»?<\/strong> Есть ли техдолг, и что о нём думают?<\/strong> В общем, если вы входите в чужой проект — лучше быть разведчиком, чем сапёром.<\/strong> А если вы клиент — подготовьте поле, чтобы следующая команда не ушла так же быстро, как предыдущая.<\/p>\n",
"date_published": "2025-04-14T17:15:33+03:00",
"date_modified": "2025-04-14T17:15:29+03:00",
"tags": [
"Инструменты и сервисы"
],
"image": "https:\/\/alexeyit.ru\/pictures\/mine.jpg",
"_date_published_rfc2822": "Mon, 14 Apr 2025 17:15:33 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "65",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/mine.jpg"
]
}
},
{
"id": "57",
"url": "https:\/\/alexeyit.ru\/all\/avtomatizirovali-yandeks-treker\/",
"title": "Концерт по заявкам: как мы автоматизировали Яндекс.Трекер",
"content_html": " Недавно в одном из профессиональных чатов снова всплыл вопрос о Яндекс.Трекере. Оказалось, что мы не единственные, кто активно использует его в работе агентства. <\/p>\n Хотя, по моим субъективным наблюдениям, большинство коллег все-таки сидят на Битриксе24 или Jira — но это уже другая история.<\/p>\n За несколько лет использования Трекера мы успели хорошо разобраться в системе. Она своеобразная, со своими особенностями, но в целом довольно гибкая и мощная. Где-то лежит начатая статья про всю автоматизацию, которую мы внедрили: там и сам Трекер, и самописные решения, и связка с Google Таблицами, и внутренняя аналитика. В общем, «цифры, цифры, цифры», но руки до этой статьи пока не дошли.<\/p>\n Сегодня хочу поделиться конкретным списком автоматизаций, которые мы используем в работе. Что-то мы придумали сами, что-то подсмотрели в чате, а что-то посоветовали коллеги. Возможно, вам что-то из этого пригодится для вашего бизнеса, проектов или команд.<\/p>\n Важно понимать: многие триггеры у нас связаны между собой. Например, один добавляет комментарий к задаче, другой тут же шлёт его в Telegram.<\/p>\n У нас довольно много задач в статусе «Отложено» — это своеобразный бэклог. Они ждут своего часа. Чтобы не теряться в этом потоке, мы сделали так: как только автор активирует задачу, триггер автоматически упоминает исполнителя в комментарии, чтобы тот точно не пропустил новую работу.<\/p>\n Когда исполнитель завершает работу и задача переходит в статус «Ожидаем проверки», система автоматически призывает в комментарии автора или менеджера, чтобы они проверили результат.<\/p>\n Если задача готова, но ещё не протестирована, триггер уведомляет нашего QA-специалиста. Он получает уведомление, берет задачу в свою очередь и приступает к тестированию.<\/p>\n Мы больше работаем со списками, чем с канбаном. Но в Яндекс.Трекере, в отличие от Битрикса или Wrike, просроченные задачи в списке ничем не выделяются. Чтобы решить этот момент, у нас настроен триггер, который проверяет дедлайны. Если задача просрочена, в ней автоматически появляется комментарий с упоминанием автора и исполнителя: «Ребята, тут что-то не так».<\/p>\n Мы считаем, сколько раз задача вернулась на доработку. Это один из наших показателей качества постановки и исполнения задач.<\/p>\n В Трекере есть специальное поле — своего рода флажок «ждём ответа от пользователя». Но если задача закрыта и полностью готова, понятно, что никаких ответов уже не требуется. Поэтому при закрытии задача автоматически очищается от этого флажка.<\/p>\n Если задача по каким-то причинам откладывается после полного цикла работы (например, требует доп. согласований), у неё обычно остаются заполненные даты начала и дедлайна. Чтобы не возникало путаницы, при переводе в статус «Отложено» все даты автоматически обнуляются. Этот статус у нас своего рода «бутылочное горлышко»: если задачу решат активировать заново, через него точно пройдут.<\/p>\n Как только по задаче появляется оценка, триггер отправляет её в нашу внутреннюю систему для дальнейшей обработки и аналитики.<\/p>\n Мы внимательно следим за качеством процессов. Исполнитель может оценить постановку задачи по 5 параметрам по 5-балльной шкале. В свою очередь, автор задачи (менеджер или инициатор) оценивает исполнителя по аналогичным критериям. Эти данные идут в систему для последующего анализа.<\/p>\n У нас есть Telegram-бот, который уведомляет о отпусках, новостях и другой важной информации. Мы интегрировали с ним и Яндекс.Трекер. Теперь любой комментарий в задаче автоматически уходит в нужный чат, и команда сразу видит, что происходит.<\/p>\n Все данные о потраченном времени, которые исполнители заносят в Трекер, автоматически передаются в нашу систему учёта. Про саму миграцию на этот подход и нюансы можно рассказать отдельно — это целая история.<\/p>\n У нас есть промежуточный статус «Активно» — задача должна быть в работе. Но иногда исполнитель по каким-то причинам не приступает к ней вовремя. Если наступает дата начала задачи, а статус остаётся «Активно», система пишет комментарий: «Почему задача не в работе?». Это помогает авторам вовремя отреагировать.<\/p>\n Чтобы все задачи были структурированными, мы используем шаблон описания. Автоматизация добавляет этот шаблон в тело задачи при создании.<\/p>\n При старте задачи важно, чтобы QA мог заранее подключиться, дать советы или увидеть возможные проблемы. Поэтому у нас есть триггер, который автоматически добавляет QA в наблюдатели.<\/p>\n С переходом на учёт времени мы стали следить за тем, чтобы задачи укладывались в оценку. В каждой задаче есть поле «Оценка» — например, 8 часов. Если исполнитель начинает выходить за рамки, появляется прогресс-бар. Чтобы автор был в курсе перерасхода, триггер шлёт уведомление: «Обрати внимание, задача выходит за пределы оценки». Всё это внедрено максимально лояльно, без излишнего контроля, но помогает следить за процессом.<\/p>\n P.S.<\/strong> Термины «Автор» и «Исполнитель» могут звучать сухо, но это стандартные обозначения из самого Яндекс.Трекера — так просто удобнее и привычнее.<\/p>\n Конечно, у всех этих триггеров есть свои нюансы, иногда случаются казусы и даже зацикливания, но это уже тема для отдельного разговора.<\/p>\n",
"date_published": "2025-03-17T09:18:55+03:00",
"date_modified": "2025-07-22T11:31:03+03:00",
"tags": [
"Инструменты и сервисы",
"Управление проектами и командами"
],
"image": "https:\/\/alexeyit.ru\/pictures\/trak2.png",
"_date_published_rfc2822": "Mon, 17 Mar 2025 09:18:55 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "57",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/trak2.png"
]
}
},
{
"id": "43",
"url": "https:\/\/alexeyit.ru\/all\/pro-pilotazh-na-sobesedovanii\/",
"title": "Про пилотаж на собеседовании",
"content_html": " Собеседование — это всегда вызов как для кандидата, так и для интервьюера. В эпоху повсеместного использования ИИ и доступности информации становится все сложнее оценить реальные знания и навыки соискателя. <\/p>\n Сегодня поговорим о том, как трансформировать стандартный опросник в увлекательный кейс.<\/p>\n Данный текст является продолжении рубрики про собеседования.<\/p>\nLLM-боты пришли, а управление пока не завезли<\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/mis.png\")
\n<\/div>\n
На ряде наших проектов мы столкнулись с крайне агрессивным поведением бота от Apple и других<\/strong>. По всем признакам это был их LLM или что-то очень близкое. Он настолько часто и плотно дёргал страницы<\/strong>, что нагрузка на сервер стала напоминать DDoS<\/strong>. В какой-то момент пришлось резать его по IP<\/strong>, иначе прод начинал просто ложиться.<\/p>\n
Звучит красиво. На практике не работает.<\/strong><\/p>\n
— у нас уже есть sitemap.xml<\/strong>;
— есть robots.txt<\/strong>;
— и главное нейросети и так умеют читать HTML<\/strong>.<\/p>\n
Ни OpenAI<\/strong>, ни Google<\/strong>, ни Anthropic<\/strong>, ни Яндекс<\/strong> публично не подтвердили поддержку этого стандарта<\/strong>.<\/p>\n
Изначально из желания дать нейросетям «чистый» контент без HTML-мусора<\/strong>. Но проблема в том, что LLM уже давно этот мусор переваривают без особых сложностей<\/strong>. Контекстные окна растут, понимание структуры документов улучшается. Через год-два нейросети будут читать сайты почти как люди<\/strong> и необходимость в отдельном markdown-файле исчезнет сама собой.<\/p>\nЧто имеем на практике<\/h2><\/p>\n
SaaS был ошибкой? Возможно. Часть 4<\/strong><\/h1><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/price2.png\")
\n<\/div>\n
Прошлые главы — раз<\/a>, два <\/a>и три <\/a>— задавали контекст. С тех пор прошёл месяц, и изменений накопилось больше, чем я ожидал.<\/p>\nМесяц кастдевов<\/strong><\/h3><\/p>\n
Сменить позиционирование<\/strong><\/h3><\/p>\n
Что сделали по разработке<\/strong><\/h3><\/p>\n
Интересные находоки<\/strong><\/h3><\/p>\n
Что дальше<\/strong><\/h3><\/p>\n
Доделываем стратегии.
Включаем рекламу и аутрич.
А дальше — посмотрим, что покажут цифры и люди.<\/p>\n",
"date_published": "2025-11-19T14:39:32+03:00",
"date_modified": "2025-11-19T15:02:23+03:00",
"tags": [
"E-commerce и маркетплейсы",
"Инструменты и сервисы",
"Личный опыт и размышления",
"Репрайсер",
"Технологии и разработка",
"Управление проектами и командами"
],
"image": "https:\/\/alexeyit.ru\/pictures\/price2.png",
"_date_published_rfc2822": "Wed, 19 Nov 2025 14:39:32 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "127",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/price2.png"
]
}
},
{
"id": "121",
"url": "https:\/\/alexeyit.ru\/all\/cepi-markova-v-e-commerce\/",
"title": "Цепи Маркова в e-commerce: как предсказывать поведение клиентов и находить сбои в системах",
"content_html": "![\"\"](\"https:\/\/alexeyit.ru\/pictures\/chin.png\")
\n<\/div>\n
<\/strong>Все эти блоки “с этим покупают” и “вам может понравиться” — чистая цепь Маркова.
Система не “угадывает”, она просто знает, что после чайника чаще всего открывают фильтры, потом кружки, а потом уже идут в корзину. Алгоритм подсовывает следующее звено, чтобы не дать цепи оборваться.<\/p>\n
“Цена упала → CTR вырос → корзины заполнились → возврат вырос → скидку убрали → продажи просели”.
А теперь представьте, что система видит эту последовательность заранее и подстраивает стратегию — вот уже и “умное ценообразование” готово.<\/p>\n
Это про понимание вероятностей, которые движут вашим процессами<\/strong>. Про то, как данные превращаются в действия. И про то, что даже “случайность” в поведении клиентов на самом деле довольно предсказуема — если у вас достаточно истории кликов, заказов и цен. <\/p>\n",
"date_published": "2025-10-24T16:12:33+03:00",
"date_modified": "2025-10-24T16:12:29+03:00",
"tags": [
"E-commerce и маркетплейсы",
"Инструменты и сервисы"
],
"image": "https:\/\/alexeyit.ru\/pictures\/chin.png",
"_date_published_rfc2822": "Fri, 24 Oct 2025 16:12:33 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "121",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/chin.png"
]
}
},
{
"id": "118",
"url": "https:\/\/alexeyit.ru\/all\/guardprice-reprayser-dlya-ozon-wildberries-yandeks-marketa-lamod\/",
"title": "GuardPrice — репрайсер для Ozon, Wildberries, Яндекс.Маркета, Lamoda, М.Видео-Эльдорадо и Аптека.ру",
"content_html": "![\"\"](\"https:\/\/alexeyit.ru\/pictures\/price.png\")
\n<\/div>\nПуть по граблям<\/strong><\/h3><\/p>\n
От коробки к полноценному SaaS<\/strong><\/h3><\/p>\n
Поддержка площадок<\/strong><\/h3><\/p>\n
Балансировка и прокси<\/strong><\/h3><\/p>\n
Маркетплейсы всеми силами пытаются это закрыть: антибот-механизмы, проверка user-агентов, капчи, блокировки IP — полный набор.<\/p>\n
Перепробовали десятки пулов и форматов, пока не поняли, что дело не только в самих прокси, но и в нагрузке по времени, частоте запросов и очередности IP<\/strong>.<\/p>\nДальше — красота, аналитика и новые грабли<\/strong><\/h3><\/p>\n
Дальше — новые рынки, новые функции и, конечно, новые грабли<\/strong>. О них вы знаете, где почитать. Подписывайтесь — впереди самое интересное.<\/strong><\/p>\n",
"date_published": "2025-10-15T14:48:40+03:00",
"date_modified": "2025-10-15T14:48:34+03:00",
"tags": [
"Инструменты и сервисы",
"Личный опыт и размышления"
],
"image": "https:\/\/alexeyit.ru\/pictures\/price.png",
"_date_published_rfc2822": "Wed, 15 Oct 2025 14:48:40 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "118",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/alexeyit.ru\/pictures\/price.png"
]
}
},
{
"id": "95",
"url": "https:\/\/alexeyit.ru\/all\/oshibki-seo-prodvizheniya-kuda-uhodit-byudzhet-i-pochemu-sayt-ne\/",
"title": "Ошибки SEO продвижения: куда уходит бюджет и почему сайт не даёт трафика",
"content_html": "Дергается глаз от некоторых SEO-задач. Почему? Обсудим<\/strong><\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/SEO.png\")
\n<\/div>\nДёргается глаз, горит пукан<\/strong><\/h2><\/p>\n
Как появляются такие задачи<\/strong><\/h2><\/p>\n
В реальности? 500 товаров, по 20 одинаковых ошибок на карточке.
Даже если исправите — ничего не изменится. Но отчёт станет красивее. И можно сказать: «Работаем. Оптимизируем».<\/p>\nКогда SEO нет — и это ещё хуже<\/strong><\/h2><\/p>\n
Где действительно лежит трафик<\/strong><\/h2><\/p>\n
Как еще достать трафика<\/strong><\/h2><\/p>\n
Вроде есть — но не работает<\/strong><\/h2><\/p>\n
Куда действительно стоит вкладываться<\/strong><\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/mine.jpg\")
\n<\/div>\n
— 💀 легаси
— 📄 много\/мало документации
— 🤷♂️ и всё вытекающее<\/p>\n
Просто так никого не меняют. Это долго и затратно.
Обычно причина — медленно делают, дорого берут, или делают «как-то не так».
Но бывает, что дело не в них: сроки были космические, ТЗ писалось на салфетке, а команду казнили «ритуально». Лучше это знать до входа в проект, а не через пару спринтов.<\/p>\n
Git, история коммитов, ветки, .gitignore, админка — это как медицинская карта проекта.
По этим вводным уже можно понять, жив проект или скорее в коме.
Если всё в порядке — круто. Если хаос — значит, закладываем время на реанимацию.<\/p>\n
Обновлённое ли окружение, какие версии пакетов, насколько всё запущено или хорошо.
Сервер — это не просто железо. Если на нём правят прод через nano — ну, ты понял.
Как обстоят дела с бэкапами.<\/p>\n
Вероятнее всего — нет. Но если вдруг есть — это праздник. И повод порадоваться команде, что была до нас.<\/p>\n
ЛПР — лицо принимающее решения. Его нужно найти и познакомиться.
Потому что можно потратить кучу времени на фичу или дизайн, а потом окажется, что согласовывать всё должен человек, которого ты даже в переписке не видел. И всё по новой.<\/p>\n
Сколько команд уже сменилось? Были ли свои разработчики? Сколько раз всё начинали с нуля?
Контекст важен. Он может объяснить, почему одни фичи «просто есть», а другие «мы не трогаем это с 2018 года».<\/p>\n
Важно понять, что клиент считает успехом.
Быстрое развитие? Безопасность? Рефакторинг? Чтобы ничего не трогали вообще?
Если ожидания не совпадают с реальностью — беда будет не в коде, а в коммуникации.<\/p>\n
Есть ли трекер задач, кто их ставит, есть ли процессы ревью и деплоя?
Бывает, проект выглядит как корабль, но рулит им один человек в шторм и без карты.
Хорошо бы это понять до того, как вы станете штурманом.<\/p>\n
Если он на связи, быстро принимает решения, участвует — шансы на успех выше.
Если «напишите бота и отпишитесь через месяц» — нужно закладывать время на «ожидание ответа от клиента».<\/p>\n
Технический долг есть почти везде. Но важно: осознают ли это? Хотят ли с ним что-то делать?
Если не хотят — это их право. Главное, чтобы вы знали, с чем работаете, и могли это оценить.<\/p>\n![\"\"](\"https:\/\/alexeyit.ru\/pictures\/trak2.png\")
\n<\/div>\nУведомление исполнителя об активации задачи<\/strong><\/h2><\/p>\n
Уведомление автора о готовности задачи<\/strong><\/h2><\/p>\n
Уведомление QA<\/strong><\/h2><\/p>\n
Просроченные задачи<\/strong><\/h2><\/p>\n
Подсчет возвратов на доработку<\/strong><\/h2><\/p>\n
Автоматическая очистка поля «Ждёт ответа»<\/strong><\/h2><\/p>\n
Очистка дат при переходе в «Отложено»<\/strong><\/h2><\/p>\n
Оценка задач<\/strong><\/h2><\/p>\n
Сбор обратной связи: оценки автора и исполнителя<\/strong><\/h2><\/p>\n
Интеграция комментариев с Telegram<\/strong><\/h2><\/p>\n
Учёт затрат времени<\/strong><\/h2><\/p>\n
Контроль невзятых задач<\/strong><\/h2><\/p>\n
Шаблон описания для задач<\/strong><\/h2><\/p>\n
Назначение QA-наблюдателя<\/strong><\/h2><\/p>\n
Уведомление о перерасходе времени<\/strong><\/h2><\/p>\n
![\"\"](\"https:\/\/alexeyit.ru\/pictures\/aviahqs.png\")
\n<\/div>\n