SEO для программистов #2

Чтобы далеко не ходить, давайте разберем SEO с технической стороны. Что нужно знать и делать если ваш сайт участвует в поиске.

1. Подсказки самих поисковиков

SEO это не против поисковиков, это вместе с поисковиками. У каждой такой системы есть панель управления, где выводятся все нужные показатели от качества сайта до производительности и ошибок. В яндексе это вебмастер, в гугле серч консоль. И то и то должно быть подключено. Внутри уже можно бродить по разделам и изучать, что это такое и как с этим жить

2. Производительность

Запомните два главных слова: Core Vitals. Это ключевые показатели, которые должны быть в зеленой зоне. По хорошему они ставятся как часть KPI для разработчиков. Никто кроме них за это не отвечает и не может сделать правильно. Остальное как обычно, высокая скорость отдачи, кеширование всего и вся, лейзи, использование последних версий http, cdn и чо там еще можно придумать. Эти показатели можно отслеживать через кабинеты в поисковиках + page speed

Следите за скриптами в тег менеджерах (гугл и яндекс) их можно грузить отложенно почти всегда (кроме счетчиков), что очень сильно сказывается на показателях + ощущениях людей.

3. Разметка

Сервер должен отдавать html. Либо серверная шаблонизация (классика), либо ssr. Никакого рассчета на то, что поисковик проиндексирует ваш js. Да, в теории он может, но на практике это дорого поэтому индексация не надежна и будет происходить сильно дольше и без гарантий.

Обязательно заголовки в правильном порядке (от h1 по h6). Бывает что разработчики вместо заголовков делают дивы с большим размером шрифта. Это шляпа.

Мета теги тоже важны. Минимум: title, description и canonical. Последний имеет очень важное значение для правильности индексации и не так просто как может показаться, особенно если речь идет про постраничную навигацию. Тут лучше копнуть в статьи или ИИ.

В целом нужно прогонять верстку через валидатор и не допускать косяков.

Микроразметка. Если вы не знакомы или не используете Schema то самое время начать внедрять. Это спец указание для разных роботов о том что на вашей странице в структурированном виде. Такая разметка часто влияет на то, как ваш сайт отображается в поиске и это сильно его выделяет среди конкурентов.

Еще внезапно альты для картинок. Они участвуют в поиске по картинкам, некоторые проекты так хорошо собирают трафик.

4. Перелинковка

Это ответственность сеошников, но разработчикам знать полезно. Важно правильно распределять веса на сайте, чтобы поисковик выбирал нужные (самые релевантные) страницы для выдачи. Концепция следующая, больше всего внутренних ссылок должно быть на главную, затем на продуктовые лендинги, затем категории, затем статьи и так далее. Даже если разделы у вас другие, принцип думаю понятен. Где это смотреть? В том самом гугл серч консоли вам все показывают и подсказывают.

5. Ошибки

Смотрим в кабинеты поисковиков и устраняем все проблемы, от 404 и 500 до страниц закрытых от индекса в robots.txt (этого недостаточно). Ошибок должно быть мало в процентном отношении к количеству проиндексированных страниц. В целом следим за корректностью кодов и правильными редиректами.

6. Мобилки

Сейчас весь поиск мобайл-ферст. Это значит, что сайт на мобилках должен летать и соответствовать хорошей доступности плюс адаптивность конечно. Если это не так, то пессимизация в поиске гарантирована. Где смотреть? Кабинеты + page speed и аналоги.

7. Индексация

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

- Не индексировать то, что не ищут (не давать ссылок на внутренние разделы, использовать мета тег noindex, а не robots.txt)
- Делать и загружать в кабинетах sitemap.xml
- Использовать по месту noindex, nofollow.

Ссылки: Телеграм | Youtube | VK

В гостях — Андрей Кобец, фронтенд-разработчик, преподаватель и человек с огромным опытом в IT, начавший путь в 2004 году. Мы вспоминаем, как выглядела разработка двадцать лет назад: первые проекты на PHP, устройство на работу «по знакомству», собеседования в Яндекс, жизнь внутри команды Метрики, офлайн-формат работы и зарождение российских соцсетей.

Обсуждаем, как в отсутствие курсов и системных материалов приходилось самостоятельно искать путь в профессию, чем отличались собеседования тех лет, какую роль играли софтскилы в офлайн-командах, как менялись подходы к образованию, и почему функциональное программирование стало для многих настоящим откровением. youtube.com/watch?v=7MeMdrgJ2Uo

Альтернативные ссылки: Аудио | vk

Именованный роутинг

Как в большинстве бекенд фреймворков определяются роуты? Мы описываем шаблон маршрута, например, /products/:id, который связываем с обработчиком. Например:

fastify.get('/products/:id', (request, reply) {
  return { hello: 'world' }
})

Это все хорошо работает, до тех пор, пока нам не нужно на эти маршруты ссылаться. Что мне придется сделать, если из одного такого обработчика, понадобится сделать редирект куда-то? Почти наверняка это будет конкатенация или интерполяция чтобы собрать нужный адрес: const url = "/products" + id. И все, приплыли.

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

С фронтендом будет похожая ситуация, если не используется какая-нибудь автогенерация sdk по openapi. В этом случае серверные маршруты где-то будут хардкодиться напрямую в клиентских приложениях.

Что собственно делать? Если фреймворк поддерживает именованные маршруты, то использовать их, если нет - найти либы, которые добавляют такую поддержку в ваш фреймворк. Либо встроить эту поддержку если вам интересен опенсорс.

/func main() {
 app := fiber.New()

 // Именованный маршрут
 app.Get("/users/:id", func(c *fiber.Ctx) error {
  return c.SendString("User " + c.Params("id"))
 }).Name("user.show")

 // Генерация URL по имени
 app.Get("/", func(c *fiber.Ctx) error {
  url := app.GetRoute("user.show").URL(fiber.Map{
   "id": "42",
  })
  return c.SendString("URL: " + url)
 })

 app.Listen(":3000")
}

⁃ Gin (go): поддержки нет, но люди хотят https://github.com/gin-gonic/gin/issues/3795
⁃ Spring Boot (java): поддержка есть из коробки, но сборка урла многословная
⁃ В Rails, Laravel, Django встроенная поддержка

Но это только на уровне бека. А что насчет фронта? Под некоторые фреймворки реализованы либы, которые берут серверный роутинг и переносят его во фронтенд причем с типами ts, например для рельсы мы юзаем https://github.com/railsware/js-routes. Я знаю что такой же есть в пыхе.

import { post_path } from '../routes';

alert(post_path(1))

Ссылки: Телеграм | Youtube | VK