Задача была ясная: написать статью для журнала, так чтобы раскрыть максимально и не скучно.
Вот только не указали стиль изложения...
Заказчику я предоставила не одинокий текстовый листочек, а папку с вариантами написания статьи.
Сколько времени заняло?
2 дня подготовка, 1,5 часа работы.
Для первого варианта пришлось почитать онлайн-журналы
аналитические блоги на WordPress, Medium или в отраслевых онлайн-журналах. О! Это было здорово!
В итоге вышла статья без мемов, без шуток в лоб, но с тонкой иронией, спрофессиональной лексикой и ощущением, что автор "в теме".
Для второго варианта статьи пришлось два дня посидеть на форумах IT, собрала факты из реальных обсуждений в IT-среде и экспертов, чтобы получилась информативная, живая, с лёгким цинизмом статья на целых 5 минут чтения (lol очень долго;))
На основе этих моих готовых статей уже начала в наглую дерзить.
Цитата из переписки:
могу:
😎 сделать ещё более дерзкую версию — почти стендап
🔥 написать вариант от лица разработчика-циника
🌍 или адаптировать под Medium / Habr / зарубежный IT-блог
🙏 Написать совершенно "чоппорную" аналитическую статью, которая соберёт максимум просмотров
Любой вариант текста доступен!🥰
Да, это это новый жанр.
И мне самой нравится этот эксперимент!👋🚀weeey
1 фрагмент.
1. Различие инженерной и SEO-логики
Разработка программного обеспечения строится на принципах предсказуемости, воспроизводимости и строгой причинно-следственной связи. Корректно написанный код при одинаковых входных данных всегда должен выдавать один и тот же результат.
SEO, напротив, опирается на вероятностную модель. Алгоритмы поисковых систем непрерывно изменяются, а результат оптимизации зачастую становится заметен лишь спустя недели или месяцы. Для разработчика это выглядит как отсутствие чёткой обратной связи: изменения внедрены, но эффект не гарантирован и не всегда измерим в привычных инженерных метриках
2. SEO как постфактум-требование
Одной из ключевых причин негативного отношения к SEO является момент его внедрения. На практике задачи поисковой оптимизации часто появляются уже после завершения основной разработки, когда архитектурные решения приняты, структура проекта зафиксирована, а продукт выведен в продакшн.
В таких условиях SEO-требования могут затрагивать фундаментальные элементы системы: URL-структуру, рендеринг страниц, работу с метаданными, скорость загрузки и логику маршрутизации. Для разработчика это означает необходимость переработки уже стабильных компонентов, что воспринимается как регресс, а не развитие.
😀
Вариант 2 с юмором, чисто технарский язык для молодежи:
🧠 Почему разработчики избегают SEO в своих проектах
*Иронично-аналитический экскурс для IT-читателя*
Если вы думали, что SEO — это просто «потому что маркетологи так сказали», то держите шлем: сейчас мы нырнем под капот индустрии, где к SEO в коде относятся примерно так же, как к комментарию `// TODO: исправить` в прод-ветке. Итак, почему же разработчики так настороженно (а иногда и с искренней ненавистью) обходят SEO-задачи стороной?
🚫 1. SEO — это как непрошеный QA-тест, который никогда не кончается
Представьте: вы наконец допилили фичу, закоммитили, релиз прошёл. Можно радоваться.
Но нет — к вам подходит SEO-специалист и говорит: «Проверим микроразметку?»
Через неделю: «Скорость можно ещё улучшить?»
Ещё через — «Пожалуйста, AMP-страницы… RSS-выгрузки…»
И так без конца.
По сути, это постоянная петля новых требований, которые *не имеют чётких границ* и зачастую меняются настолько часто, что напоминают бесконечный `while(true) { optimize(); }`. ([Work In Net][1])
---
🔗 2. SEO и код — как кот и пылесос: вроде должны мирно сосуществовать, но…
SEO требует внести правки туда, куда разработчик давно уже не смотрел — метатеги, ЧПУ-URL, карты сайта, редиректы, robots.txt, адаптивность…
Нормальный фронтендер о таких вещах вспоминает лишь когда Git выдаёт «конфликт мёрджа».
И дело не просто в количестве правок, а в том, что часто они приходят *постфактум*, когда архитектура уже заморожена. Тогда оптимизатор просит изменить фундамент — а это, скажем мягко, нервирует. ([Habr][2])
⚡ 3. SEO ≠ Производительность — но почему разработчики думают иначе
Разработчик ценит чистый код, модульность, архитектуру, CI/CD, высокую скорость загрузки, оптимизированную память…
А SEOшник хочет быстрее результаты в выдаче — и начинает мерить их количеством ключевых слов и позициями в поиске.
Эти KPI-миры редко пересекаются без боли. Один хочет стабильности, второй — видимости.
Результат: дев собирается в мини-лагерь «SEO побоку» и ставит на рюкзак новый стикер «Я оптимизирую только свой отдых». ([Habr][2])
🧩 4. SEO как вечный рефакторинг: «ещё чуть-чуть»
Кажется, SEO — это просто добавить пару метатегов?
Ха-ха.
На практике это часто похоже на бесконечный рефакторинг — мелкие улучшения, которые перерастают в большие вопросы. Почему карточки товаров не индексируются? Почему страница не получает трафик? Почему сниппеты пусты?
И у разработчика возникает ощущение, что он не пишет софт, а участвует в бесконечном UX-аудите, где требования изменяются быстрее, чем версия Next.js. ([Work In Net][1])... конец фрагмента
Пожаловаться
