Изучите основы и лучшие практики 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 и обеспечивает быстрый Time-To-First-Byte (TTFB).
Static SSR — это, как следует из названия, статический режим. Это означает, что вы можете использовать модель компонентов Blazor для реализации страниц, но после рендеринга веб-страницы в браузере никакой интерактивности не будет. Это отличный выбор для статических страниц, таких как упомянутые выше.
Interactive Server означает, что интерактивность выполняется на сервере, а клиент получает чистый HTML-ответ. Из-за интерактивности TTFB медленнее, чем у Static SSR.
Interactive Auto и Interactive WebAssembly сложнее для SEO. В целом я не рекомендую использовать их для SEO-ориентированных веб-приложений, если у вас нет достаточного опыта и понимания того, как правильно реализовать пререндеринг.
Что на самом деле видят поисковые роботы (краулеры)
Чтобы лучше понять теорию из предыдущей главы, рассмотрим следующий стартовый код HTML, который видит браузер для веб-приложения Blazor WebAssembly (с отключенным пререндерингом):
И сравните его с тем же приложением, реализованным с использованием Static SSR:
При использовании Static SSR чистый HTML-ответ отправляется клиенту и рендерится в браузере. Поисковые роботы могут читать контент страницы, индексировать его и использовать для предоставления содержательных страниц результатов поиска (SERP).
Помимо содержимого страницы, метаданные остаются крайне важными для SEO и превью в социальных сетях.
Метатеги, такие как теги title и description, используются для формирования SERP.
Это определение метаданных моего личного веб-сайта.
Вы можете видеть, что заголовок и описание, заданные мной в коде, используются для создания 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 и доступности.
Вы можете совершить и множество других ошибок, но эти четыре охватывают самые важные темы и помогут вам начать работу.
Почему предварительный рендеринг в Blazor имеет значение
Эта глава относится только к приложениям Blazor WebAssembly. При предварительном рендеринге веб-приложение сначала отрисовывается на сервере, а затем перерисовывается на клиенте после полной загрузки приложения.
Это вызывает мерцание страницы, поскольку содержимое заменяется во время второго цикла рендеринга.
До появления .NET 10 некоторые разработчики отключали предварительный рендеринг. Однако без него клиенту не отправляется никакой HTML-код до загрузки страницы. Это плохо для SEO, как мы узнали ранее.
Начиная с .NET 10, атрибут PersistentState помогает смягчить эту проблему, позволяя использовать предварительный рендеринг без мерцания.
Совет: всегда используйте предварительный рендеринг при применении Blazor WebAssembly, чтобы избежать проблем с SEO и производительностью.
Совет: всегда используйте предварительный рендеринг при применении Blazor WebAssembly, чтобы избежать проблем с SEO и производительностью.
Практические рекомендации
Основываясь на своем более чем шестилетнем опыте разработки веб-приложений на Blazor в различных условиях, я рекомендую по возможности использовать статический SSR.
Для интерактивных компонентов учитывайте последствия для SEO и сложность, которую вы добавите в проект, выбрав Blazor WebAssembly вместо Blazor Server. Для большинства проектов Blazor Server является лучшим вариантом, по крайней мере на ранних этапах.
Для полностью внутренних приложений SEO может не иметь значения. Тем не менее, доступность и превью, отображаемое при отправке ссылок на внутренние приложения, могут стать вескими причинами для реализации заголовка, описания и тегов Open Graph во всех ваших приложениях Blazor. В качестве лучшей практики я рекомендую всегда добавлять эти метатеги.
Если вам по уважительной причине приходится использовать Blazor WebAssembly, я настоятельно рекомендую правильно реализовать предварительный рендеринг. Это важно для производительности и удобства использования приложения, а также влияет на SEO.
Заключение
Выбор правильного режима рендеринга, использование правильных элементов метаданных и реализация удобных для SEO URL-адресов — все это важнейшие шаги для того, чтобы ваше приложение оставалось обнаруживаемым, доступным и хорошо работало для пользователей и поисковых систем.
Следуя лучшим практикам, таким как использование статического SSR для публичных страниц, правильное управление метаданными и использование предварительного рендеринг при необходимости, вы можете создавать высоко оптимизированные веб-приложения Blazor.
Внимание к этим деталям поможет вашим приложениям, будь то общедоступные или внутренние, и обеспечит лучший пользовательский опыт.
Если вы хотите узнать больше о разработке на Blazor, посмотрите мой бесплатный экспресс-курс по Blazor на YouTube. И следите за обновлениями в блоге Telerik, чтобы узнать больше об основах Blazor.
