Как SEO связано с разработкой: то, что невозможно исправить одним копирайтингом

SEO часто воспринимают как работу с текстами. Собрать ключевые слова. Написать статьи. Добавить заголовки. Получить ссылки. Но даже идеальный контент может не дать результата, если сам сайт технически мешает поисковой системе его увидеть, понять и корректно индексировать. Поэтому SEO находится на пересечении двух зон: маркетинга и разработки . Маркетинг отвечает за то, что именно хочет найти пользователь. Разработка — за то, сможет ли поисковая система нормально получить, прочитать и интерпретировать этот контент. Именно поэтому часть SEO-проблем невозможно решить одним копирайтингом.

Где заканчивается контент и начинается разработка

Упрощённо зоны ответственности можно разделить так.

Маркетинг отвечает за:

• semantics;
• keyword intent;
• content;
• links.

Development отвечает за:

• HTML semantics;
• performance;
• sitemap;
• robots;
• canonical;
• redirects;
• structured data;
• mobile;
• rendering.

На практике эти зоны постоянно пересекаются. Например, маркетолог может правильно определить поисковый запрос и написать отличную страницу под него. Но если:

• страница плохо рендерится;
• canonical указывает не туда;
• sitemap не обновляется;
• URL дублируется;
• мобильная версия неудобна;

результат может быть значительно хуже ожидаемого. 1. Rendering: сможет ли поисковик вообще увидеть контент Один из самых важных технических вопросов: Как формируется содержимое страницы? В классическом серверном сайте HTML приходит пользователю уже готовым. Поисковая система получает:

• заголовки;
• текст;
• ссылки;
• метаданные;
• структуру страницы.

Но современные сайты часто используют JavaScript. Например:

• SPA;
• React;
• Vue;
• Angular;
• динамические frontend-приложения.

Сам по себе JavaScript не является проблемой. Проблема возникает, когда основной контент появляется только после сложного клиентского выполнения кода. Представим страницу услуги. Пользователь открывает её в браузере и видит:

• заголовок;
• описание;
• цены;
• FAQ;
• кейсы.

Но первоначальный HTML почти пустой. Всё содержимое загружается позже через JavaScript. Если поисковый робот не сможет корректно получить или обработать этот контент, прекрасный текст может вообще не решить проблему. То есть маркетинг сделал свою работу. Контент есть. Но технически он доставляется не лучшим способом. Для SEO-проектов поэтому важно заранее выбирать подходящий вариант:

• SSR;
• SSG;
• pre-rendering;
• server-rendered templates;
• корректно реализованный dynamic rendering.

Главный принцип: ключевой контент должен быть доступен поисковой системе предсказуемо. 2. Performance: скорость влияет не только на удобство Медленная страница — это не просто раздражение для пользователя. Она может создавать проблемы сразу на нескольких уровнях. Например:

• страница долго становится интерактивной;
• изображения блокируют загрузку;
• JavaScript слишком тяжёлый;
• сервер долго отвечает;
• мобильная версия загружается заметно хуже desktop.

Для SEO важно, чтобы сайт был технически эффективным. Разработчики могут улучшать:

• размер изображений;
• lazy loading;
• WebP/AVIF;
• cache;
• CSS;
• JavaScript bundles;
• server response;
• CDN;
• database queries;
• third-party scripts.

Иногда сайт можно значительно улучшить для поиска вообще без изменения текста. Просто сделав его быстрее и стабильнее. 3. Semantic HTML: структура должна быть понятна машине Человек видит страницу визуально. Поисковая система анализирует ещё и её структуру. Поэтому важно, какие HTML-элементы используются. Например:

• <header>;
• <nav>;
• <main>;
• <article>;
• <section>;
• <footer>;
• <h1>;
• <h2>;
• <h3>.

Если вся страница построена как набор безымянных <div>, поисковой системе сложнее понять структуру документа. Особенно часто проблемы возникают с заголовками. Например:

• несколько H1 без логики;
• пропущенная иерархия;
• заголовки сделаны через <div>;
• текст визуально выглядит как заголовок, но семантически им не является.

Для пользователя страница может выглядеть абсолютно нормально. Для поисковой системы — быть менее понятной. Хорошая разработка помогает контенту быть структурированным не только визуально, но и машинно. 4. Sitemap: поисковой системе нужна карта сайта Sitemap помогает поисковым системам находить страницы сайта. Особенно это важно, если:

• страниц много;
• контент регулярно добавляется;
• есть журнал;
• каталог;
• кейсы;
• товары;
• динамические разделы.

Типичная проблема: сайт развивается, новые страницы публикуются, но sitemap остаётся статичным. В результате часть новых URL туда просто не попадает. Для SEO лучше, когда sitemap формируется автоматически из CMS или приложения. Например: при публикации новой статьи она автоматически появляется в sitemap. Это снижает количество ручной работы и вероятность ошибки. 5. robots.txt: один файл может закрыть половину сайта robots.txt кажется мелочью. Пока в нём не появляется неправильное правило. Например, после переноса проекта со staging на production случайно остаётся:

Disallow: / Для бизнеса сайт работает. Пользователи его открывают. Реклама ведёт трафик. Но поисковому роботу фактически говорят: Не заходи сюда. Такие ошибки особенно неприятны потому, что визуально сайт остаётся полностью рабочим. Поэтому robots.txt должен проверяться как часть релиза. Особенно после:

• миграции;
• смены домена;
• редизайна;
• переноса staging → production;
• изменения структуры сайта.

6. Canonical: какой URL считать главным Один и тот же контент иногда доступен по нескольким адресам. Например: /services /services/ /services?utm_source=... /category/services Для пользователя это может быть одна и та же страница. Для поисковой системы — разные URL. Canonical помогает указать основной адрес. Ошибки здесь могут привести к тому, что:

• индексируется не та версия страницы;
• страницы конкурируют друг с другом;
• сигналы распределяются между дублями.

Это уже не проблема текста. Это проблема реализации URL и метаданных. 7. Redirects: старые страницы нельзя просто удалять После редизайна или миграции структура сайта часто меняется. Было: /service/web-development Стало: /services/websites Если старый URL просто удалить, пользователь и поисковая система получат 404. При массовом изменении структуры это может привести к потере накопленного поискового трафика. Поэтому нужен redirect mapping. Старые URL должны корректно вести на новые. Особенно важно это при:

• смене CMS;
• редизайне;
• миграции;
• изменении каталога;
• переименовании разделов.

Хорошая миграция сайта включает не только новый дизайн. Она включает сохранение старых URL-сигналов там, где это возможно. 8. URL architecture: структура адресов тоже важна URL — часть архитектуры сайта. Сравните: /page?id=3729 и /services/web-development Второй адрес:

• понятнее пользователю;
• проще поддерживать;
• логичнее для структуры сайта;
• удобнее для аналитики.

Но важнее не красота URL сама по себе. Важно, чтобы структура была последовательной. Например: /services/ /services/design/ /services/development/ /services/audit/ Так поисковой системе и пользователю проще понимать иерархию. Плохая URL-архитектура часто появляется, когда сайт растёт без общего плана. Сначала пять страниц. Потом пятьдесят. Потом разные разделы начинают создавать URL по разным правилам. Исправлять это спустя годы значительно дороже. 9. Structured data: помочь поисковику понять сущности Поисковая система видит текст страницы.

Но иногда ей можно дополнительно объяснить, что именно находится на странице. Для этого используется structured data. Например:

• Organization;
• Article;
• Product;
• BreadcrumbList;
• FAQ;
• LocalBusiness.

Это позволяет структурированно описать сущности сайта. Например: эта страница — статья. У неё есть:

• автор;
• дата;
• заголовок;
• изображение.

Или: эта страница описывает компанию. У неё есть:

• название;
• адрес;
• контакты.

Structured data не заменяет хороший контент. Она помогает поисковой системе лучше его интерпретировать. 10. Mobile-first: SEO начинается со смартфона Сайт может быть идеальным на большом мониторе и неудобным на телефоне. Например:

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

Это влияет не только на UX. Мобильная версия — важная часть технического качества сайта. Для многих проектов именно мобильный пользователь составляет основную аудиторию. Особенно для:

• локального бизнеса;
• медицины;
• стоматологии;
• недвижимости;
• ресторанов;
• услуг;
• ecommerce.

Поэтому мобильную версию нельзя оставлять на конец разработки как «адаптацию desktop». Её нужно проектировать как полноценный интерфейс. 11. Internal linking: ссылки — часть архитектуры Внутренняя перелинковка часто воспринимается как SEO-задача редактора. Но она также зависит от разработки. Например, сайт может автоматически связывать:

• статьи;
• услуги;
• кейсы;
• категории;
• товары.

Хорошая архитектура позволяет строить логические связи между страницами. Например, статья: Как выбрать CMS может вести на:

• услугу разработки;
• страницу аудита;
• кейс миграции CMS.

А страница услуги — обратно на связанные статьи. Так формируется понятная сеть контента. Если же CMS не позволяет нормально добавлять ссылки, связанные материалы или breadcrumbs, маркетинг оказывается ограничен самой системой. 12. SEO часто ломается во время редизайна Парадоксально, но новый сайт иногда становится хуже старого именно с точки зрения SEO. Причины типичные:

• изменили URL;
• не настроили redirects;
• забыли canonical;
• закрыли часть сайта от индексации;
• потеряли metadata;
• изменили headings;
• удалили старый контент;
• sitemap не обновили;
• JavaScript rendering реализовали неудачно.

Внешне новый сайт красивее. Но поисковый трафик падает. Именно поэтому SEO должно участвовать в разработке до релиза, а не после него. Маркетинг и разработка должны работать вместе Правильное SEO нельзя полностью отдать только маркетологу или только разработчику. Маркетинг отвечает за: что ищет человек какой контент отвечает на запрос какие страницы нужны какие темы связаны Разработка отвечает за: как этот контент доставляется можно ли его индексировать как быстро работает страница как устроены URL как поисковый робот понимает структуру

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

• хороший заголовок;
• поисковый интент;
• экспертный текст;
• FAQ;
• кейсы;
• внутренние ссылки.

Но сайт — SPA. HTML при первом запросе почти пустой. Контент подгружается сложным JavaScript после нескольких API-запросов. Если Googlebot не может нормально получить этот контент, прекрасный текст может вообще не решить проблему. То же самое работает в обратную сторону. Можно построить идеально быстрый технический сайт. Но если на странице нет полезного содержания и она не отвечает на запрос пользователя, одна разработка тоже не даст хорошего SEO-результата. Технический SEO-чеклист для разработки Перед запуском или модернизацией сайта полезно проверить:

1. Основной контент доступен без проблем с rendering.
2. HTML имеет нормальную semantic structure.
3. На странице корректно используется H1–H3.
4. Сайт нормально работает на mobile.
5. Страницы загружаются достаточно быстро.
6. Sitemap формируется и обновляется.
7. robots.txt не закрывает важные разделы.
8. Canonical настроен корректно.
9. Старые URL перенаправляются через redirects.
10. Нет лишних дублей страниц.
11. URL architecture последовательна.
12. Structured data добавлена там, где она полезна.
13. Внутренняя перелинковка поддерживается CMS.
14. Metadata можно менять без разработчика.
15. SEO-настройки проверяются перед production release.

Хорошая CMS тоже влияет на SEO SEO становится дорогим, если каждое изменение требует разработчика. Маркетинговая команда должна иметь возможность самостоятельно:

• менять title;
• менять description;
• редактировать headings;
• публиковать статьи;
• создавать страницы;
• управлять canonical;
• добавлять alt;
• менять URL там, где это безопасно;
• настраивать redirects.

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

• rendering;
• routing;
• templates;
• CMS;
• redirects;
• structured data;
• sitemap.

То есть снова возвращаться к разработке. Гораздо дешевле учитывать эти требования заранее. Подход VERB В VERB SEO рассматривается не как отдельный слой текста поверх готового сайта. Мы смотрим на него как на часть продукта. Поэтому при разработке и модернизации важно проверить:

• rendering;
• performance;
• semantic HTML;
• sitemap;
• robots.txt;
• canonical;
• redirects;
• structured data;
• URL architecture;
• mobile;
• internal linking;
• возможности CMS.

После этого маркетинг получает техническую основу, на которой уже можно нормально работать с:

• семантикой;
• keyword intent;
• контентом;
• ссылками.

Хороший текст не должен бороться с плохой архитектурой

SEO работает лучше, когда маркетинг и разработка усиливают друг друга. Можно написать идеальную статью. Но если поисковой системе сложно получить её содержимое, проблема не решается ещё одним текстом. Можно купить ссылки. Но если старые страницы после редизайна возвращают 404, часть ценности теряется. Можно собрать хорошую семантику. Но если CMS не позволяет создавать нужные landing pages, маркетинг становится зависим от разработки. Поэтому SEO нужно оценивать не только на уровне контента. Нужно смотреть на сайт целиком.

Хотите понять, какие технические проблемы мешают SEO?

VERB может провести технический аудит сайта и проверить:

• rendering;
• скорость;
• HTML structure;
• sitemap;
• robots.txt;
• canonical;
• redirects;
• structured data;
• URL architecture;
• mobile;
• внутреннюю перелинковку;
• возможности CMS.

На выходе — не общий отчёт «улучшить SEO», а конкретная карта технических проблем и приоритетов. Пришлите сайт на аудит — проверим, что мешает поисковой системе нормально увидеть, понять и индексировать ваш продукт.