SEO techniczne w Next.js App Router: metadane, mapy stron i JSON-LD
Dowiedz się, jak narzędzia do współdzielonych metadanych, domyślne ustawienia układu, plik robots.ts, dynamiczny sitemap, poprawne dane JSON-LD oraz audyty stron zapewniają aplikacji Next.js solidną bazę pod SEO.
Źródła: How I Got a Next.js Project to 100% SEO on Lighthouse
Aplikacja Next.js może wyglądać na ukończoną, a mimo to być trudna do przetworzenia przez wyszukiwarki: strony nie mają kanonicznych adresów URL, zasady działania crawlerów są niesprecyzowane, a nowy treść nigdy nie trafia do mapy stron. Niniejszy przewodnik opisuje rozwój strony z API wykorzystującym dane symulacyjne, obejmujący wiele stron zasobowych od pierwszej audytu SEO Lighthouse do uzyskania wyniku 100, przy czym pokazane są siedem zmian wprowadzonych za pomocą wbudowanych API metadanych w App Routerze.
Tworzenie metadanych strony za pomocą jednego narzędzia pomocniczego
Ręczne wpisywanie metadanych na każdej stronie prowadzi do błędów, takich jak brakujący adres URL kanoniczny tu albo przestarzały tytuł Open Graph tam. Mała „fabryka” rozwiązuje ten problem: każda strona przekazuje jedynie swój tytuł, opis, ścieżkę oraz opcjonalną flagę noIndex, a narzędzie pomocnicze przekształca je w pola kanoniczne, przeznaczone dla robotów i Open Graph:
export function createPageMetadata({
title,
description,
path,
noIndex = false,
}: PageMetadata) {
return {
title,
description,
alternates: {
canonical: path,
},
robots: noIndex ? "noindex, nofollow" : "index, follow",
openGraph: {
title,
description,
url: path,
type: "website",
},
};
}
Indeksowanie jest opcjonalne: jedna flaga zmienia stronę na noindex, nofollow. Ponieważ path jest względny, narzędzie pomocnicze polega na adreście bazowym zdefiniowanym w rozkładzie korzeniowym.
Ustaw domyślne wartości dla całego strony w rozkładzie korzeniowym
Wszystko, co jest wspólne dla całej strony, powinno znajdować się w eksporcie metadata z pliku layout.tsx:
metadataBase- szablon tytułu
- domyślny opis
- domyślne ustawienia Open Graph
- ustawienia karty Twittera
- domyślne ustawienia robota
- atrybut
langw elemencie<html>
Odpisane wersja tego eksporu wygląda następująco:
export const metadata: Metadata = {
metadataBase: new URL("https://mockdata.ir"),
title: {
default: "MockData",
template: "%s | MockData",
},
description: "...",
};
Za pomocą szablonu %s | MockData strona z tytułem „Users API” jest renderowana jako „Users API | MockData”, natomiast strony bez tytułu używają wartości default. To właśnie metadataBase przekształca względne wartości canonical oraz URL Open Graph pomocnika na adresy URL bezwzględne. Należy pamiętać, że lang nie jest polem metadanych; należy je ustawić w tagu <html>, który jest renderowany przez układ.
Definiowanie zasad przeglądania przez roboty za pomocą robots.ts
Zamiast pozostawić zasady przeglądania nieokreślone, należy wygenerować plik robots.txt na podstawie pliku app/robots.ts, który zwraca obiekt typu MetadataRoute.Robots.
export default function robots(): MetadataRoute.Robots {
return {
rules: {
userAgent: "*",
allow: "/",
},
sitemap: "https://mockdata.ir/sitemap.xml",
};
}
Jest celowo minimalny: wszystkie agenty użytkownika mogą przeglądać wszystko, a lokalizacja mapy stron jest podana jasno.
Generowanie mapy stron na podstawie swoich danych
Z powodu stron zasobów dla użytkowników, wpisów, produktów i wielu innych elementów, ręcznie utrzymywany plan strony XML nie nadaje się do skalowania. Wyjście domyślne pliku sitemap.ts może być async, dzięki czemu może ono wysyłać zapytania do tego samego źródła, które są używane przez strony:
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
const resources = await getPublicResources();
return [
{
url: "https://mockdata.ir",
lastModified: new Date(),
},
...resources.map((resource) => ({
url: `https://mockdata.ir/${resource.slug}`,
lastModified: resource.updatedAt,
})),
];
}
Każdy zasób jest mapowany na adres URL, w którym updatedAt zastępuje lastModified, dzięki czemu nowe publiczne zasoby automatycznie trafiają do planu strony. Jedna poprawka: użycie new Date() dla strony głównej sugeruje zmianę przy każdej generacji; prawdziwy czas ostatniej modyfikacji treści jest bardziej dokładny.
Dodawaj dane strukturyzowane tylko tam, gdzie to aktualne
JSON-LD z słownikiem Schema.org informuje wyszukiwarki o tym, co reprezentuje dana strona. Sam aplikacja jest opisywana jako SoftwareApplication, a używane typy to:
WebSiteOrganizationSoftwareApplication
BreadcrumbListCeluj w dokładność, a nie objętość: metadane muszą opisywać treści rzeczywiście obecne na stronie. Wymyślone recenzje, oceny lub inne sfabrykowane informacje są mylące i mogą naruszać zasady motorów wyszukiwania.
Zachowuj spójność ścieżek nawigacyjnych w interfejsie użytkownika i schemacie
Strony dokumentacji ułożone w formie drzewa pokazują widoczną ścieżkę, np. Strona główna → Dokumentacja → API użytkowników, a ta sama hierarchia jest emitowana jako dane strukturalne BreadcrumbList. Widoczna ścieżka oraz metadane powinny zawsze opisywać tę samą strukturę.
Ręcznie sprawdzaj każdą stronę nadającą się do indeksowania
Na koniec przejrzyj każdą publiczną stronę osobno:
- Czy ma dokładnie jedno wyraźne H1?
- Czy tytuł opisuje tę konkretną stronę?
- Czy opis odpowiada rzeczywistej treści?
- Czy istnieją przydatne linki wewnętrzne do niej i z niej?
- Czy ta strona w ogóle powinna być indeksowana?
- Czy jakieś puste lub mało wartościowe strony są dostępne dla robotów przeglądających?
Nie każda ścieżka powinna znaleźć się w wynikach wyszukiwania; noindex jest często właściwym rozwiązaniem. Jeśli chodzi o strukturę nagłówków, zapoznaj się z tym przewodnikiem po semantycznym HTML dotyczącym aspektu zapisu kodu.
Co oznacza, a co nie oznacza doskonała ocena SEO w Lighthouse
Po tych korektach Lighthouse poinformował o ocenie SEO na poziomie 100. Ta liczba sprawdza podstawy techniczne, takie jak tytuły, opisy i możliwość przeglądania strony; nie mówi nic o pozycjonowaniu. Pozycjonowanie zależy od jakości treści, intencji wyszukiwania, autorytetu, linków zwrotnych, konkurencji, wydajności oraz wielu innych czynników.
Prawdziwa wartość leży w solidnej bazie. Przeprowadzenie audytu przed publikacją aplikacji Next.js jest tanie i pomaga wykryć wiele drobnych błędów.
Główne wnioski
- Zcentralizuj metadane strony w specjalnym pliku pomocniczym i ustaw wspólne wartości domyślne, w tym
metadataBase, w rozkładzie głównym. - Wykorzystaj plik
robots.tsoraz asynchroniczny pliksitemap.ts, aby zasady przeglądarki i adresy URL były zsynchronizowane z twoimi danymi. - Dodawaj tylko dane strukturyzowane, które dokładnie opisują stronę, oraz utrzymuj identyczne ścieżki nawigacyjne w interfejsie użytkownika i schemacie.
- Rozważaj użycie atrybutu
noindexjako prawomocnego rozwiązania dla stron, które nie powinny pojawić się w wynikach wyszukiwania. - Ocenę Lighthouse na poziomie 100 interpretuj jako „technicznie poprawną”, a nie jako gwarancję wysokiego rankingu.
Powiązane materiały
- Migracja z next/router: Parametry, płytkie adresy URL i błędy 404 w App Router — Dowiedz się, jak parametry, funkcja useParams, aktualizacje płytkich adresów URL, nawigacja programowa oraz rzeczywiste strony 404 funkcjonują w Next.js App Router po usunięciu next/router.
- Gdzie pokreślić linię serwer-klient w stronie App Router w Next.js — Praktyczny model mentalny dla komponentów serwerowych w React: co działa gdzie, jak strona posta na blogu dzieli się na części serwerową i kliencką oraz jakie zasady importu należy przestrzegać.