Изучите основы и лучшие практики SEO (поисковой оптимизации) в Blazor.
К концу этой статьи вы поймете, почему SEO в Blazor работает иначе, чем в традиционных ASP.NET Core MVC или Razor Pages, и почему это может быть важно для ваших приложений, даже если вы пока об этом не задумывались.
Почему SEO важно (даже для внутренних приложений)
Нам нужно различать публичные веб-приложения на Blazor и внутренние корпоративные системы.
Для публичных приложений поисковая оптимизация важна, чтобы клиенты могли найти приложение в Google и других поисковых системах.
Однако, если вы считаете, что это не важно для внутренних приложений, подумайте вот о чем: SEO также влияет на превью при обмене ссылками (внутренние инструменты коммуникации, такие как Microsoft Teams и аналоги), доступность, ИИ-краулеры и семантическую индексацию внутренних сайтов.
В той или иной форме SEO влияет на все современные веб-приложения, независимо от того, являются ли они публичными.
Различия в SEO между режимами рендеринга Blazor
В предыдущих версиях Blazor, Blazor в целом и Blazor WebAssembly в частности имели плохую репутацию в плане SEO. И эта репутация основана на фактах, а не только на ощущениях.
Однако в современном .NET 10+ Blazor предлагает гораздо более гибкие режимы рендеринга. Качество SEO в целом зависит от выбранного режима рендеринга, а не от Blazor как фреймворка.
Blazor предоставляет четыре режима рендеринга:
Для публичных маркетинговых страниц, таких как главная страница (лендинг) веб-приложения, документация, блоги или другие страницы продуктов, я настоятельно рекомендую использовать Static SSR.
Static SSR обеспечивает наилучшую производительность SEO, так как сервер возвращает чистый HTML и обеспечивает быстрое время до первого байта (TTFB).
Static SSR — это, как следует из названия, статический режим. Это означает, что вы можете использовать модель компонентов Blazor для реализации страниц, но после рендеринга страницы в браузере никакой интерактивности не будет. Это отличный выбор для статических страниц, упомянутых выше.
Interactive Server означает, что интерактивность выполняется на сервере, а клиент получает чистый HTML-ответ. Из-за интерактивности TTFB медленнее, чем в Static SSR.
Interactive Auto и Interactive WebAssembly более сложны для SEO. В целом, я бы не советовал использовать их для SEO-ориентированных веб-приложений, если только у вас нет опыта работы с ними и вы не знаете, как правильно реализовать предварительный рендеринг (prerendering).
Что на самом деле видят поисковые роботы
Чтобы лучше понять теорию из предыдущей главы, рассмотрим следующий стартовый HTML-код, который видит браузер для веб-приложения Blazor WebAssembly (с отключенным предварительным рендерингом):
И сравните его с тем же приложением, реализованным с использованием Static SSR:
При использовании Static SSR чистый HTML-ответ отправляется клиенту и отображается в браузере. Поисковые роботы могут прочитать содержимое страницы, проиндексировать его и использовать для предоставления значимых результатов поиска (SERP).
Помимо содержимого страницы, метаданные остаются очень важными для SEO и превью в социальных сетях.
Мета-теги, такие как теги title и description, используются для формирования поисковой выдачи (SERP).
Это определение метаданных моего личного сайта.
Вы видите, что заголовок и описание, которые я определил в коде, используются для создания результата в Google.
Теги Open Graph позволяют настроить контент, который отображается при публикации ссылки в Facebook, LinkedIn и X (ранее Twitter).
Наиболее важные теги:
- og:title — заголовок контента
- og:description — краткое описание страницы
- og:image — URL изображения, которое появится при публикации ссылки
- og:url — канонический URL контента
- og:type — тип контента (статья, веб-сайт, видео и т. д.)
Подсказка: Канонический URL — это основная версия веб-страницы. Он часто используется, когда несколько URL указывают на один и тот же контент. Его цель — решить и предотвратить проблемы с дублирующимся контентом, когда разные URL возвращают одинаковое содержимое.
Подсказка: Канонический URL — это основная версия веб-страницы. Он часто используется, когда несколько URL указывают на один и тот же контент. Его цель — решить и предотвратить проблемы с дублирующимся контентом, когда разные URL возвращают одинаковое содержимое.
Вы можете редактировать статические метаданные непосредственно в файле App.razor. Однако чаще всего вам нужно, чтобы описание и тег заголовка динамически менялись в зависимости от страницы, которую вы отображаете.
Существует несколько встроенных компонентов, таких как PageTitle, который позволяет нам устанавливать текст вкладки браузера из каждой страницы Blazor.
Аналогично, компонент HeadContent позволяет нам устанавливать метаданные с каждой страницы Blazor. Рассмотрим следующий пример:
Мы используем компонент HeadContent и устанавливаем тег description внутри нашей страницы Blazor. Представьте, что эта страница предоставляет динамический контент. Например, в зависимости от предоставленного ID статьи отображается другая статья.
Мы устанавливаем свойство Description в разделе кода и ссылаемся на него в шаблоне.
Маршрутизация и SEO-дружественные URL
Независимо от используемой веб-технологии, важно внедрять SEO-дружественные (и понятные для людей) маршруты.
Хороший пример: /products/blazor-grid
Плохой пример: /page?id=42
Вы хотите, чтобы URL были короткими, но информативными. Осмысленные маршруты помогают людям и машинам лучше понимать содержимое страницы.
Маршруты всегда должны быть определены в нижнем регистре, следует избегать случайных глобально уникальных идентификаторов (GUID) в дополнение к идентификаторам объектов.
В хороших приложениях маршруты максимально стабильны. Это означает, что капитальный ремонт веб-приложения не должен требовать полной переработки структуры URL. В противном случае вы рискуете нарушить существующие ссылки и закладки.
В Blazor мы используем директиву @page с параметрами для интуитивного построения таких маршрутов:
Производительность важна для SEO
Помимо правильного предоставления метаданных и отрендеренного HTML, производительность становится все более важным фактором в ранжировании веб-сайтов в SEO.
Использование Static SSR там, где это возможно, и применение интерактивных «островков», таких как интерактивное поле поиска или калькулятор цен, — это современный архитектурный подход, который мы должны принять для Blazor и другой веб-разработки.
На практике это означает, что мы реализуем несколько компонентов без интерактивности (Static SSR) и применяем интерактивный режим рендеринга к конкретным компонентам, таким как поле поиска.
Четкое разделение динамического и статического контента дает много преимуществ, включая лучшую поддержку и производительность.
Распространенные ошибки новичков
Давайте обсудим четыре самые распространенные ошибки, которые я вижу у новичков в SEO для веб-приложений на Blazor:
Ошибка №1: Выбор WebAssembly для маркетинговых страниц
Blazor WebAssembly часто не идеален для контентных сайтов, ориентированных на SEO. Он долго загружается и усложняет рендеринг (предварительный рендеринг).
Ошибка №2: Забывать о метаданных для каждой страницы
Каждая релевантная страница должна иметь как минимум теги title и description. Для публичных приложений я бы также добавил теги Open Graph на каждую страницу.
Ошибка №3: Рендеринг контента только после вызовов API
Страница должна выглядеть максимально полной даже без данных, предоставляемых API. Поисковые роботы считывают веб-сайт, не выполняя вызовы API. Например: всегда отрисовывайте структуру таблицы, даже если вы загружаете её содержимое через вызов API.
Ошибка №4: Игнорирование семантического HTML
Даже при использовании пользовательских компонентов правильная реализация HTML по-прежнему важна. Использование <main>, <article>, <section> и других тегов помогает установить четкую иерархию страницы, что способствует SEO и доступности.
Существует еще много ошибок, которые можно совершить, но эти четыре охватывают самые важные темы и помогут вам начать.
Почему предварительная отрисовка (prerendering) в Blazor важна
Эта глава применима только к приложениям Blazor WebAssembly. При предварительной отрисовке веб-приложение сначала отображается на сервере, а затем повторно отрисовывается на клиенте после полной загрузки приложения.
Это вызывает мерцание страницы, так как содержимое заменяется во время второго цикла отрисовки.
До выхода .NET 10 некоторые разработчики отключали предварительную отрисовку. Однако без неё клиенту не отправляется никакой HTML до загрузки страницы. Это плохо для SEO, как мы выяснили ранее.
Начиная с .NET 10, атрибут PersistentState помогает смягчить эту проблему, позволяя использовать предварительную отрисовку без мерцания.
Совет: всегда используйте предварительную отрисовку при работе с Blazor WebAssembly, чтобы избежать проблем с SEO и производительностью.
Совет: всегда используйте предварительную отрисовку при работе с Blazor WebAssembly, чтобы избежать проблем с SEO и производительностью.
Практические рекомендации
Основываясь на моем опыте разработки веб-приложений на Blazor в течение более шести лет в различных условиях, я рекомендую использовать статическую серверную отрисовку (Static SSR) везде, где это возможно.
Для интерактивных компонентов учитывайте последствия для SEO и сложность, которую вы добавите в проект, выбрав Blazor WebAssembly вместо Blazor Server. Для большинства проектов Blazor Server является лучшим вариантом, по крайней мере на ранних этапах.
Для полностью внутренних приложений SEO может быть не важно. Тем не менее, доступность и предварительный просмотр, который отображается при обмене ссылками на внутренние приложения, могут быть причинами для реализации заголовков, описаний и тегов Open Graph во всех ваших приложениях Blazor. В качестве передовой практики я рекомендую всегда включать эти метатеги.
Если вам необходимо использовать Blazor WebAssembly по веской причине, я настоятельно рекомендую правильно реализовать предварительную отрисовку. Это важно для производительности и удобства использования приложения, а также имеет значение для SEO.
Заключение
Выбор правильного режима отрисовки, использование правильных элементов метаданных и реализация SEO-дружественных URL-адресов — все это важные шаги для того, чтобы ваше приложение оставалось доступным, удобным и эффективным для пользователей и поисковых систем.
Следуя передовым практикам, таким как использование Static SSR для публичных страниц, правильное управление метаданными и использование предварительной отрисовки при необходимости, вы можете создавать высокооптимизированные веб-приложения на Blazor.
Внимание к этим деталям поможет вашим приложениям, будь то публичные или внутренние, и обеспечит лучший пользовательский опыт.
Если вы хотите узнать больше о разработке на Blazor, посмотрите мой бесплатный экспресс-курс по Blazor на YouTube. И следите за блогом Telerik, чтобы узнать больше об основах Blazor.
