Когда не трогать код: уроки из технического SEO для разработчиков

Я всегда считал, что техническое SEO — это про meta-теги, canonical URLs и schema.org. Пока не начал вести собственный блог и не обнаружил, что главный навык здесь — не добавлять код, а вовремя остановиться. Это оказалось удивительно похоже на мои pain points в разработке.

Ошибка №1: Лечить несуществующие проблемы

В первые месяцы я реагировал на каждый подозрительный сигнал из Search Console как на production-инцидент:

// Было:
if (googleIndexingStatus !== 'SUCCESS') {
  rewriteEntirePageStructure(); // Spoiler: обычно не нужно
}

// Стало:
const waitForNaturalIndexing = (signal) => {
  if (!isCriticalIssue(signal)) {
    await sleep(2_WEEKS); // Часто помогает больше, чем рефакторинг
  }
};

То же самое происходит с performance-оптимизацией. Сколько раз я:

Внедрял сложный lazy-loading для изображений ниже fold, хотя Lighthouse показывал 98/100
Рефакторил React-компоненты из-за “медленного” TTI, который на деле укладывался в 75-й перцентиль
Добавлял premature-оптимизации типа Web Workers там, где обычный memoization решал проблему

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

Документирование как способ разработки

Когда я перестал писать статьи “про лучшие практики” и начал документировать реальные эксперименты, изменилось всё:

Статический анализ vs реальные данные
Раньше я советовал next/image потому что “так правильно”. Теперь у меня есть сравнительные тесты:
- CDN vs on-demand optimizers
- WebP adoption в разных регионах
- Fallback-стратегии для старых устройств

Живая документация
Вместо застывших “документационных тайлов” мой блог теперь выглядит как лабораторный журнал:

## Update 2024-03-15
После обновления Google Core Web Vitals threshold:
- LCP в 2.8s теперь считается "Good" (было 2.5s)
- CLS 0.1 → 0.25
Актуальные метрики для EU: [...]

Признание ошибок
Когда моя рекомендация по preconnect для Google Fonts оказалась вредной после изменений в Chrome, я не редактировал старую статью, а добавил:

⚠️ Warning: совет из этого поста теперь anti-pattern. Современный подход — […]

Преимущество маленьких проектов

В корпоративной разработке мы часто не можем позволить себе “неидеальные” решения. Но в личных проектах:

Можно зафиксировать промежуточный этап: “Вот как я настроил headers в Next.js, хотя понимаю, что это не optimal”
Допустимо сказать: “Пока не знаю, почему getStaticProps здесь медленнее SSR”
Полезно показать dead ends: “Потратил 3 дня на оптимизацию, выиграл 12ms — не стоит того”

Такой подход неожиданно улучшил и мою основную работу. Теперь я чаще:

Создаю ADRs (Architecture Decision Records) с контекстом, а не просто “правильные” решения
Фиксирую failed-эксперименты во внутренней wiki
Провожу brownbag-сессии типа “Как мы ошиблись с кэшированием”

Что попробовать на этой неделе

Метод “Три вопроса” перед рефакторингом
Прежде чем оптимизировать код, спроси:
- Есть ли доказательства, что проблема реальна?
- Насколько критично её исправлять прямо сейчас?
- Каков риск регрессии?

Хроники ошибок
Создай в проекте файл ANTI-PATTERNS.md с примерами:

### Избыточный prefetch
**Симптомы**: High memory usage на мобильных устройствах  
**Ошибочное решение**: `<link rel="prefetch" href="/all-products.json">`  
**Правильно**: Dynamic import по необходимости + границы загрузки

Замеряй twice, оптимизируй once
Прежде чем внедрять сложное решение (например, Rust-модуль для вычислений), проверь:
- Как часто выполняется операция?
- Каков разброс значений в продакшене?
- Есть ли более простые способы (memoization, debounce)?

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

Источник: https://dev.to/seogeotech/i-built-a-technical-seo-website-the-biggest-lesson-had-nothing-to-do-with-seo-o9n