Overskriftsystem: H1-, H2- og H3-regler

Et overskriftsystem er det ordnede settet av én sidetittel og dens seksjonsetiketter. Det gjør en lang side om til en lesbar rute for mennesker og en maskinlesbar disposisjon for søkemotorer, hjelpeteknologi og AI-svarsystemer.

Sidetittelen over er denne sidens eneste H1. Hver hovedspesifikasjon nedenfor er en H2, og enhver underinndeling inne i en hovedseksjon er en H3. Denne levende disposisjonen er det gjengitte elementet: nivåene uttrykker relasjoner snarere enn skriftstørrelser.

Hvorfor dette elementet betyr noe

Lesere går sjelden gjennom en lang side i én sammenhengende gjennomlesing. De skanner etter et gjenkjennelig spørsmål, sammenligner seksjonsetiketter med deres nåværende behov og bestemmer hvor de skal senke farten. Beskrivende overskrifter reduserer denne innsatsen fordi hver enkelt gir et lite løfte om hva som følger. «Hvordan stabile overskrifts-ID-er bevarer siteringer» er nyttig ved første øyekast; «Noen flere tanker» er det ikke.

Det samme hierarkiet støtter maskinell utvinnbarhet, noe som betyr at et automatisert system kan identifisere en seksjon, forstå hvordan den forholder seg til sideemnet og hente den uten å forveksle den med en naboseksjon. H1 etablerer sideemnet. H2 deler det emnet inn i primære temaer. H3 snevrer inn én H2 til en metode, et tilfelle, et kriterium eller et unntak. Et hoppet nivå skjuler denne relasjonen og tvinger en tolk til å gjette om en underseksjon er et søsken, et barn eller en urelatert blokk.

Overskrifter skaper også adresserbare seksjoner. En fragmentidentifikator er den delen av en URL etter #, for eksempel #qa-checklist. Søkeresultater, interne lenker, nettleserbokmerker og AI-svar kan peke til den eksakte destinasjonen. En tilfeldig omdøpt autogenerert ID kan derfor bryte en URL selv når siden fortsatt eksisterer. Overskriften er ikke dekorasjon: teksten definerer seksjonen og ID-en blir en varig offentlig adresse.

Følg skrivereglene for elementer når en seksjons formål samsvarer med et typebestemt element. En H2 kalt «Advarsel» erstatter ikke en advarselsboks, og en H2 kalt «Sammenligning» erstatter ikke en sammenligningstabell. Overskrifter gir dokumenthierarki; typebestemte elementer gir formålsspesifikk struktur. Begge kan være nødvendige.

Når det skal brukes

Bruk overskriftsystemet på hver vesentlig indekserbar side. Selv en kort side trenger én H1. Legg til H2-seksjoner når leseren må bevege seg mellom ulike spørsmål, stadier, kriterier eller dokumentasjonsgrupper. Legg til H3-underseksjoner bare når en H2 inneholder minst to genuint forskjellige deler som drar nytte av separat navigering.

De nesten-trefferne er visuelle etiketter som ser ut som overskrifter, men som ikke hører hjemme i artikkeldisposisjonen:

• En korttittel navngir ett gjentatt kort; det er ikke automatisk en dokumentseksjon.
• En uthevingetikett som «Tips» eller «Viktig» identifiserer bokstypen; den blir ikke en H2 bare fordi den er i fet skrift.
• En diagramtittel identifiserer en figur. Den tilhører figurens bildetekst eller tilgjengelige navn, med mindre diagrammet starter en fullstendig seksjon.
• En navigasjonsetikett, brødsmule, fane, trekkspillkontroll, bunntekstoverskrift og modaltittel kan trenge komponentsemantikk, men de går ikke inn i hovedartikkelhierarkiet.
• En stor reklameslagord er presentasjonstekst. Skriftstørrelse kan ikke løfte den opp til dokumentets H1.

Ikke legg til en overskrift bare for å introdusere én setning, splitte en sammenhengende forklaring eller skape visuelt pusterom. Bruk avsnittsavstand eller redigering til disse oppgavene. En nyttig overskrift markerer en seksjon som er betydelig nok til å svare på et distinkt leserbehov.

Hvor overskrifter skal plasseres

Plassering uttrykker foreldrerelasjon. Plasser H1 i starten av hovedinnholdet, etter brødsmuler eller annen nettstednavigasjon og før introduksjonen. Plasser hver H2 før en primærseksjon. Plasser en H3 bare etter foreldrenes H2 og forelderens orienterende innhold, aldri før den første H2 og aldri som et søsken valgt for visuell fremtoning.

To overskrifter kan ikke være tilstøtende i forfattet artikkelinnhold. Hver overskrift må eie nyttig innhold før neste overskrift på samme eller dypere nivå. Denne regelen forhindrer tomme seksjonsetiketter, gir leserne kontekst før en underseksjonsliste og skaper utvinnbare passasjer i stedet for en bar disposisjon.

Anatomi

Den merkede anatomien har fem deler:

1. H1: det unike sideemnet og toppen av innholdsdisposisjonen.
2. H2: et primært spørsmål, stadium eller dimensjon innenfor det emnet.
3. H3: et barneemne som ikke kan forstås korrekt uten sin forelder-H2.
4. Eid innhold: svaret, dokumentasjonen, instruksjonene eller forklaringen mellom én overskrift og neste overskrift på samme eller høyere nivå.
5. Stabil ID: fragmentdestinasjonen festet til overskriften og bevart etter publisering.

Relasjonen forblir gyldig hvis typografien endres. Et tema kan gjengi H2 med mindre skrift på mobil, men den må forbli H2 i HTML-en. Omvendt: å gjøre et avsnitt stort og fet gir det ikke overskriftssemantikk eller en fragmentdestinasjon.

Designeksempler

Designvarianter tilsvarer semantiske nivåer og reelle innpakningstilstander, ikke vilkårlige fargealternativer.

H1-sidetittel: vis det unike emnet i starten av hovedinnholdet. En støttende beskrivelse kan følge, men ingen øyenbryn, logo eller helteslagord blir en ny H1.

H2-primærseksjon: gjør seksjonen forståelig fra en innholdsfortegnelse og følg den med innhold som etablerer omfang.

H3-underseksjon: bruk det mindre nivået fordi emnet er underordnet, ikke fordi designeren ønsker mindre tekst.

Brutt overskrift: tillat en naturlig to-linjers brytning på smale skjermer. Ikke forkort en tydelig overskrift til en tvetydig etikett bare for å holde den på én linje.

Forankrede tilstander: vis sveving og tastaturfokus uten å gjøre ankeret til den eneste måten å forstå destinasjonen på. Direkte navigering må kompensere for eventuell klebrig topptekst slik at overskriften ikke er skjult.

Parametere

Overskriftsystemet er en dokumentkontrakt snarere enn en dekorativ komponent. Parametrene definerer disposisjonen, teksten leserne ser, innholdet hver node eier, og URL-en som noden kan nås via.

Tegn- og ordgrensene er redaksjonelle rammer, ikke grunner til å utelate nødvendig spesifisitet. En overskrift på 94 tegn som skiller to lignende prosedyrer er bedre enn en kort, men misvisende. De strukturelle grensene er strenge: én H1, ingen hoppede nivåer, ingen dupliserte ID-er og ingen tomme seksjoner.

Syntaks og kodeeksempler

Den kanoniske bærbare formen pakker den opprinnelige disposisjonen inn i et heading-system-direktiv. Den første overskriften kartlegges til dokumenttittelen; senere overskrifter forblir ordnede innholdsnoder. Eksplisitte ID-er legges til når overskriftene blir offentlige.

Bærbar Markdown-direktiv

:::heading-system
# Roter en API-nøkkel uten nedetid

Erstatt legitimasjonen i hver avhengig tjeneste før du tilbakekaller den gamle nøkkelen.

## Forbered erstatningen

Registrer hver tjeneste som for øyeblikket leser legitimasjonen.

### Identifiser skjulte forbrukere

Sjekk planlagte jobber, distribusjonshemmeligheter og lokale integrasjoner.

## Verifiser og tilbakekall

Test erstatningen, tilbakekall deretter den eksponerte nøkkelen.
:::

Ved publisering, lås stabile ID-er i stedet for å la fremtidige tekstredigeringer regenerere dem:

## Forbered erstatningen {#prepare-replacement}
### Identifiser skjulte forbrukere {#identify-hidden-consumers}

Hugo-shortcode

{{< heading-system h1="Roter en API-nøkkel uten nedetid" >}}
## Forbered erstatningen {#prepare-replacement}

Registrer hver tjeneste som for øyeblikket leser legitimasjonen.

### Identifiser skjulte forbrukere {#identify-hidden-consumers}

Sjekk planlagte jobber, distribusjonshemmeligheter og lokale integrasjoner.
{{< /heading-system >}}

Dette er Hugo-adapterkontrakten, ikke en påstand om at dette registreret har en heading-system-shortcode. En Hugo-implementering kan fortsette å gjengi H1 fra frontmatter og kroppsoverskriftene via Markdown, slik denne siden gjør, forutsatt at den validerer det samme hierarkiet og bevarer eksplisitte ID-er.

WordPress-blokk

<!-- wp:heading {"level":2,"anchor":"prepare-replacement"} -->
<h2 id="prepare-replacement">Forbered erstatningen</h2>
<!-- /wp:heading -->

<p>Registrer hver tjeneste som for øyeblikket leser legitimasjonen.</p>

<!-- wp:heading {"level":3,"anchor":"identify-hidden-consumers"} -->
<h3 id="identify-hidden-consumers">Identifiser skjulte forbrukere</h3>
<!-- /wp:heading -->

WordPress bør lagre H1 i side-tittelfeltet eller en godkjent helteblokk, ikke som en andre overskriftsblokk i artikkelkroppen. Sett hver publiserte overskrifts HTML-anker eksplisitt slik at en senere ordlydsredigering ikke stille endrer URL-en.

Eksempler

Bra: disposisjonen forutsier fullstendige svar

# Hvordan velge en godkjenningsarbeidsflyt for fakturaer

## Definer godkjenningsrisikoen
Forklar hvilke fakturaverdier, leverandører og unntak som trenger gjennomgang.

### Sett verditerskler
Tildel en navngitt godkjenner til hver terskel og dokumenter hva som skjer ved grensen.

### Rute policy-unntak
Send manglende bestillinger og endrede bankdetaljer til en separat gjennomgangsbane.

## Test arbeidsflyten
Kjør vanlige og eksepsjonelle fakturaer gjennom hele ruten før lansering.

Dette fungerer fordi H1 angir én oppgave, hver H2 navngir et primært stadium, hver H3 tilhører forelderen, og hver etikett etterfølges av innhold som oppfyller løftet. En leser kan skanne disposisjonen og forutsi hvor terskler, unntak og testing dekkes.

Dårlig: styling erstatter hierarki

# Fakturagodkjenning

### Ting å tenke på
## Mer informasjon
### Unntak
### Annet

Dette mislykkes av fire uavhengige grunner. Det hopper fra H1 til H3, bruker etiketter som ikke forutsier et svar, plasserer overskrifter ved siden av hverandre uten eid innhold, og lar «Unntak» stå uten forklaring før neste overskrift. Den resulterende disposisjonen antyder dekning som siden ikke gir. Det skaper også svake autogenererte ID-er som #other, som er tvetydige når de siteres utenfor siden.

Skjemamarkering og tilgjengelighet

Overskrifter trenger ikke en frittstående Schema.org-type. H1 leverer eller speiler vanligvis headline for en Article, TechArticle eller annen passende sideenhet, men synlig ordlyd og JSON-LD må beskrive samme emne. H2- og H3-seksjoner forblir HTML-struktur; ikke lag en skjemaenhet for hver overskrift. En overskrift kalt «Ofte stilte spørsmål» skaper heller ikke FAQPage-markering av seg selv — den synlige spørsmål-og-svar-datamengden må oppfylle FAQ-elementkontrakten.

Tilgjengelighet avhenger av semantisk HTML og logisk rekkefølge. Skjermleserbrukere kan navigere etter overskrift, inspisere en overskriftsliste eller hoppe direkte mellom seksjoner. Denne arbeidsflyten bryter sammen når siden hopper over nivåer for styling, bruker fete avsnitt som falske overskrifter, eller inkluderer verktøy- og artikkeloverskrifter i ett usammenhengende hierarki.

Bruk faktiske <h1>, <h2>- og <h3>-elementer. Hold overskriftsteksten synlig; en aria-label må ikke erstatte tydelig skjermtekst. Ankerkontroller trenger et beskrivende tilgjengelig navn, synlig tastaturfokus og et klikkmål separert fra overskriftsteksten når det å lenke hele overskriften ville forvirre seleksjon. Når en fragment-URL lastes, trenger ikke tastaturfokus å flyttes automatisk, men destinasjonsoverskriften må være synlig og ikke dekket av en klebrig topptekst.

Overskrifts-ID-er må være unike innenfor siden og bør begynne med en bokstav. Hold dem i små bokstaver, med bindestrek, lesbare og fri for forbigående datoer eller posisjonsnumre. En stabil ID kan forbli #verify-results selv om den synlige overskriften forbedres fra «Verifiser resultatene» til «Verifiser at den nye legitimasjonen fungerer.» Hvis seksjonens betydning endres fullstendig, opprett en ny ID og bevar den gamle fragmentet gjennom et alias eller dokumentert omdirigeringsatferd når plattformen støtter det. Den separate ankerlenker -spesifikasjonen styrer ankernavigasjons- og interaksjonsdetaljer.

Skriveregler

Skriv sidens disposisjon før du polerer individuelle etiketter. Hver overskrift bør svare på «hva vil jeg lære, bestemme eller gjøre her?» i konkret språk. Foretrekk «Sammenlign årlige og månedlige faktureringskostnader» fremfor «Prissettingshensyn», og «Hvorfor importen avviser dupliserte ID-er» fremfor «Feilsøking». Beskrivende betyr ikke ordrikt; det betyr at etiketten forutsier seksjonens faktiske innhold.

Bruk én H1 på 20–80 tegn. Foretrekk H2- og H3-overskrifter på 2–12 ord og maks 90 tegn. En lang guide har normalt 3–12 H2-seksjoner. En H2 trenger minst én omfangs- eller svarsetning før en eventuell H3. Bruk to eller flere H3-seksjoner under en forelder når underinndeling hjelper; en enkelt H3 signaliserer ofte at innholdet bør slås sammen i H2.

Bruk setningskasus med mindre et egennavn eller produktnavn krever store bokstaver. Spørsmål er passende når seksjonen svarer på det eksakte spørsmålet umiddelbart. Forklarende etiketter passer for stadier, kriterier, funn og spesifikasjoner. Hold parallelle seksjoner grammatisk parallelle: bruk verb for en prosesssekvens, substantiv for sammenligningskriterier eller spørsmål for et FAQ-sett.

Sett aldri disse inne i overskriftstekst:

• Markdown-lenker eller rå-URL-er; de skaper konkurrerende destinasjoner og ustabile tilgjengelige navn.
• Fotnotemarkører eller kildesiteringer; plasser dokumentasjon i det eide innholdet.
• Emojier brukt som strukturelle etiketter, statusmerker eller dekorative prefikser.
• Manuell nummerering med mindre innleggstypen definerer en stabil ordnet sekvens.
• CTA-språk som «Kjøp nå», prispåstander, haster eller markedsføringsmerker.
• Stilinstruksjoner, HTML-linjeskift eller enhetsspesifikke forkortelser.
• En andre setning som hører hjemme i avsnittet under.

Ikke skriv smarte etiketter som er avhengige av omkringliggende tekst for å gi mening. «Spøkelset blir tykkere» kan passe i en essays stemme, men det gir et søkeresultat, innholdsfortegnelse, skjermlesers overskriftsliste eller AI-sitering ingen brukbar kontekst. Bevar personlighet i forklaringen etter en presis overskrift.

Innleggstyper som bruker det

Frontmatter-postTypes-arrayen driver disse relasjonene. Hver oppførte innleggstype bruker den samme hierarkikontrakten, mens dens egen anatomi bestemmer de eksakte seksjonsnavnene og rekkefølgen.

QA-sjekkliste

• Siden gjengir nøyaktig én synlig H1, og den navngir sidens faktiske emne.
• Disposisjonen går fra H1 til H2 til H3 uten hoppede nivåer.
• Hver H3 har én tydelig foregående H2-forelder.
• Hver overskrift etterfølges av meningsfylt eid innhold før neste overskrift.
• Hver H2 inkluderer en orienterende eller svarsetning før sin første H3.
• Overskriftstekst er beskrivende når den leses alene i en innholdsfortegnelse eller skjermlesers overskriftsliste.
• Parallelle seksjoner bruker parallell grammatikk og tilsvarende nivåer.
• Overskriftsnivåer gjenspeiler relasjoner, ikke skriftstørrelse eller ønsket visuell vekt.
• Typebestemte formål bruker fortsatt sine påkrevde elementer; overskrifter imiterer ikke komponenter.
• Hver publiserte overskrift har én unik, lesbar, stabil fragment-ID.
• Eksisterende fragment-ID-er forblir uendret når synlig ordlyd redigeres uten å endre seksjonens betydning.
• Direkte fragmentnavigering lar destinasjonen være synlig under eventuell klebrig topptekst.
• Overskriftstekst inneholder ingen lenker, siteringer, emoji-etiketter, markedsføringsmerker eller manuelle linjeskift.
• HTML-disposisjonen forblir sammenhengende med menyer, kort, trekkspill, modalvinduer og andre sidekomponenter til stede.
• Den gjengitte siden fungerer på smal bredde, med to-linjers overskrifter som brytes uten beskjæring eller overlapping.

Avvis siden når det visuelle designet ser polert ut, men disposisjonen mislykkes. Overskriftsfeil forverrer seg: ett hoppet nivå eller én tom seksjon gjør at hver nedstrøms forbruker må jobbe hardere for å rekonstruere relasjoner som kilden burde ha oppgitt direkte.

FAQ

Spørsmålene nedenfor løser tilfellene som mest sannsynlig skaper inkonsistente disposisjoner på tvers av redaktører og plattformer. Deres autoritative verdier lever i den strukturerte [[faq]]-frontmatteren over slik at synlig utdata og eventuell kvalifisert skjemautdata kan dele én kilde.