Overskriftsystem: H1-, H2- og H3-regler

Et overskriftsystem er det ordnede sæt af én sidetitel og dens sektionsetiketter. Det gør en lang side til en læsbar rute for mennesker og en maskinaflæselig oversigt for søgemaskiner, hjælpeteknologi og AI-svarssystemer.

Sidetitlen herover er denne sides enkelte H1. Hver større specifikation nedenfor er en H2, og enhver underopdeling inden for en større sektion er en H3. Den levende oversigt er det gengivne element: dets niveauer udtrykker relationer snarere end skriftstørrelser.

Hvorfor dette element er vigtigt

Læsere sjældent gennemgår en lang side i én uafbrudt gennemlæsning. De scanner efter et genkendeligt spørgsmål, sammenligner sektionsetiketter med deres aktuelle behov og beslutter, hvor de vil sætte farten ned. Beskrivende overskrifter reducerer denne indsats, fordi hver enkelt afgiver et lille løfte om, hvad der følger. “Hvordan stabile overskrifts-ID’er bevarer citationer” er nyttigt ved første øjekast; “Et par flere tanker” er det ikke.

Det samme hierarki understøtter maskinel ekstraherbarhed, hvilket betyder, at et automatiseret system kan identificere en sektion, forstå, hvordan den relaterer til sideemnet, og hente den uden at forveksle den med en nabosektion. H1 fastlægger sideemnet. H2 opdeler emnet i primære anliggender. H3 indsnævrer en H2 til en metode, et tilfælde, et kriterium eller en undtagelse. Et sprunget niveau skjuler denne relation og tvinger en parser til at gætte, om et underafsnit er et søskende, et barn eller en urelateret blok.

Overskrifter skaber også adresserbare sektioner. Et fragment-id er den del af en URL efter #, såsom #qa-checklist. Søgeresultater, interne links, browserbogmærker og AI-svar kan pege på netop den destination. Et tilfældigt omdøbt auto-genereret ID kan derfor bryde en URL, selv når siden selv stadig findes. Overskriften er ikke dekoration: dens tekst definerer sektionen, og dens ID bliver en holdbar offentlig adresse.

Følg element-skrivereglerne , når en sektions formål matcher et typificeret element. En H2 med navnet “Advarsel” erstatter ikke en advarselsboks, og en H2 med navnet “Sammenligning” erstatter ikke en sammenligningstabel. Overskrifter giver dokumenthierarki; typificerede elementer giver formålsspecifik struktur. Begge kan være nødvendige.

Hvornår skal det bruges

Brug overskriftsystemet på alle væsentlige indekserbare sider. Selv en kort side har brug for én H1. Tilføj H2-sektioner, når læseren skal bevæge sig mellem forskellige spørgsmål, faser, kriterier eller evidensgrupper. Tilføj H3-underafsnit kun, når en H2 indeholder mindst to virkelig forskellige dele, der har gavn af separat navigation.

De næsten-missere er visuelle etiketter, der ligner overskrifter, men ikke hører til i artikeloversigten:

• En korttitel navngiver ét gentaget kort; det er ikke automatisk en dokumentsektion.
• En callout-etiket som “Tip” eller “Vigtigt” identificerer boksens type; den bliver ikke til en H2, blot fordi den er fed.
• En diagramtitel identificerer en figur. Den hører til i figurens billedtekst eller tilgængelige navn, medmindre diagrammet begynder en komplet sektion.
• En navigationsmenuetiket, brødkrumme, fane, accordion-kontrol, sidefodsoverskrift og modal-titel kan have brug for komponentsemantik, men de indgår ikke i hovedartikelhierarkiet.
• En stor reklameslogan er displaytekst. Skriftstørrelse kan ikke forfremme den til dokumentets H1.

Tilføj ikke en overskrift blot for at introducere én sætning, opdele en sammenhængende forklaring eller skabe visuelt åndedrætsrum. Brug afsnitsafstand eller redigering til disse opgaver. En nyttig overskrift markerer en sektion, der er væsentlig nok til at besvare et bestemt læserbehov.

Hvor skal overskrifter placeres

Placering udtrykker forældreskab. Placer H1 i starten af hovedindholdet, efter brødkrummer eller anden webstedsnavigation og før introduktionen. Placer hver H2 før en primær sektion. Placer en H3 kun efter dens overordnede H2 og den overordnedes orienterende indhold, aldrig før den første H2 og aldrig som en peer valgt af visuelle årsager.

To overskrifter må ikke være tilstødende i forfattet artikelindhold. Hver overskrift skal eje nyttigt indhold før næste overskrift på samme eller dybere niveau. Denne regel forhindrer tomme sektionsetiketter, giver læserne kontekst før en underafsnitsliste og skaber ekstraherbare passager frem for en bar oversigt.

Anatomi

Den mærkede anatomi har fem dele:

1. H1: det unikke sideemne og toppen af indholdsoversigten.
2. H2: et primært spørgsmål, en fase eller dimension inden for dette emne.
3. H3: et underemne, der ikke kan forstås korrekt uden dets overordnede H2.
4. Ejet indhold: svaret, evidensen, instruktionerne eller forklaringen mellem én overskrift og næste overskrift på samme eller højere niveau.
5. Stabilt ID: fragmentdestinationen knyttet til overskriften og bevaret efter offentliggørelse.

Forholdet forbliver gyldigt, hvis typografien ændres. Et tema kan gengive H2 med mindre skriftstørrelse på mobil, men det skal forblive H2 i HTML. Omvendt gør det ikke et afsnit stort og fedt til at give det overskriftssemantik eller en fragmentdestination.

Designeksempler

Designvarianter svarer til semantiske niveauer og reelle indpakningstilstande, ikke til vilkårlige farvemuligheder.

H1-sidetitel: vis det unikke emne i starten af hovedindholdet. En understøttende beskrivelse kan følge, men intet øjenbryn, logo eller helteslogan bliver en anden H1.

H2-primærsektion: gør sektionen forståelig ud fra en indholdsfortegnelse, og følg den med indhold, der fastlægger omfang.

H3-underafsnit: brug det mindre niveau, fordi emnet er underordnet, ikke fordi designeren ønsker mindre tekst.

Indpakket overskrift: tillad en naturlig todelt linjeombytning på smalle skærme. Forkort ikke en klar overskrift til en tvetydig etiket blot for at holde den på én linje.

Forankrede tilstande: vis hover- og tastaturfokus uden at gøre ankeret til den eneste måde at forstå destinationen på. Direkte navigation skal kompensere for eventuel sticky header, så overskriften ikke er skjult.

Parametre

Overskriftsystemet er en dokumentkontrakt snarere end en dekorativ komponent. Dets parametre definerer oversigten, den tekst læserne ser, det indhold hver knude ejer, og den URL, hvorigennem knuden kan nås.

Tegn- og ordgrænserne er redaktionelle retningslinjer, ikke årsager til at udelade nødvendig specificitet. En overskrift på 94 tegn, der adskiller to lignende procedurer, er bedre end en kort, men vildledende. De strukturelle grænser er strenge: én H1, ingen sprangte niveauer, ingen dublet-ID’er og ingen tomme sektioner.

Syntaks og kodeeksempler

Den kanoniske bærbare form indpakker den oprindelige oversigt i et heading-system-direktiv. Den første overskrift kortlægges til dokumenttitlen; senere overskrifter forbliver ordnede indholdsknuder. Eksplicitte ID’er tilføjes, når overskrifterne bliver offentlige.

Bærbart Markdown-direktiv

:::heading-system
# Rotér en API-nøgle uden nedetid

Erstat legitimationsoplysningen i alle afhængige tjenester, før den gamle nøgle tilbagekaldes.

## Forbered erstatningen

Registrer alle tjenester, der aktuelt læser legitimationsoplysningen.

### Identificér skjulte forbrugere

Tjek planlagte jobs, deployeringshemmeligheder og lokale integrationer.

## Verificér og tilbagekald

Test erstatningen, og tilbagekald derefter den eksponerede nøgle.
:::

Ved offentliggørelse fastlåses stabile ID’er, så fremtidige tekstredigeringer ikke regenererer dem:

## Forbered erstatningen {#prepare-replacement}
### Identificér skjulte forbrugere {#identify-hidden-consumers}

Hugo shortcode

{{< heading-system h1="Rotér en API-nøgle uden nedetid" >}}
## Forbered erstatningen {#prepare-replacement}

Registrer alle tjenester, der aktuelt læser legitimationsoplysningen.

### Identificér skjulte forbrugere {#identify-hidden-consumers}

Tjek planlagte jobs, deployeringshemmeligheder og lokale integrationer.
{{< /heading-system >}}

Dette er Hugo-adapterkontrakten, ikke en påstand om, at dette repository registrerer en heading-system-shortcode. En Hugo-implementering kan fortsat gengive H1 fra front matter og brødtekstoverskrifter via Markdown, som denne side gør, forudsat den validerer det samme hierarki og bevarer eksplicitte ID’er.

WordPress-blok

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

<p>Registrer alle tjenester, der aktuelt læser legitimationsoplysningen.</p>

<!-- wp:heading {"level":3,"anchor":"identify-hidden-consumers"} -->
<h3 id="identify-hidden-consumers">Identificér skjulte forbrugere</h3>
<!-- /wp:heading -->

WordPress bør gemme H1 i side-titel-feltet eller en godkendt helteblok, ikke som en anden overskriftsblok i artikelbrødteksten. Sæt hver offentliggjort overskrifts HTML-anker eksplicit, så en senere ordlydsredigering ikke stille ændrer dens URL.

Eksempler

Godt: oversigten forudsiger komplette svar

# Sådan vælger du en godkendelsesworkflow til fakturaer

## Definér godkendelsesrisikoen
Forklar hvilke fakturaværdier, leverandører og undtagelser der kræver gennemgang.

### Sæt værditærskler
Tildel en navngiven godkender til hver tærskel, og dokumentér hvad der sker ved grænsen.

### Håndter politikundtagelser
Send manglende indkøbsordrer og ændrede bankoplysninger til en separat gennemgangssti.

## Test workflowen
Kør almindelige og usædvanlige fakturaer gennem hele ruten før lancering.

Dette virker, fordi H1 angiver én opgave, hver H2 navngiver en primær fase, hver H3 tilhører sin overordnede, og hver etiket efterfølges af indhold, der indfrier sit løfte. En læser kan scanne oversigten og forudsige, hvor tærskler, undtagelser og test dækkes.

Dårligt: styling erstatter hierarki

# Fakturagodkendelse

### Ting at overveje
## Mere information
### Undtagelser
### Andet

Dette fejler af fire uafhængige årsager. Den springer fra H1 til H3, bruger etiketter der ikke forudsiger et svar, placerer overskrifter ved siden af hinanden uden ejet indhold og efterlader “Undtagelser” uden nogen forklaring før næste overskrift. Den resulterende oversigt antyder dækning, som siden ikke leverer. Den skaber også svage auto-genererede ID’er som #other, der er tvetydige, når de citeres uden for siden.

Skemamarkup og tilgængelighed

Overskrifter har ikke brug for en selvstændig Schema.org-type. H1 leverer eller spejler almindeligvis headline for en Article, TechArticle eller anden passende sideenhed, men synlig ordlyd og JSON-LD skal beskrive samme emne. H2- og H3-sektioner forbliver HTML-struktur; konstruér ikke en skemaenhed for hver overskrift. En overskrift med titlen “Ofte stillede spørgsmål” skaber heller ikke FAQPage-markup af sig selv — den synlige spørgsmål-og-svar-data skal opfylde FAQ-elementkontrakten.

Tilgængelighed afhænger af semantisk HTML og logisk rækkefølge. Skærmlæserbrugere kan navigere efter overskrift, inspicere en overskriftsliste eller hoppe direkte mellem sektioner. Denne arbejdsgang bryder, når siden springer niveauer over for stilens skyld, bruger fede afsnit som falske overskrifter eller inkluderer hjælpe- og artikeloverskrifter i ét usammenhængende hierarki.

Brug faktiske <h1>, <h2>- og <h3>-elementer. Hold overskriftstekst synlig; en aria-label må ikke erstatte klar skærmtekst. Ankerkontroller har brug for et beskrivende tilgængeligt navn, synligt tastaturfokus og et klikmål adskilt fra overskriftsteksten, når linkning af hele overskriften ville forvirre markering. Når en fragment-URL indlæses, behøver tastaturfokus ikke at flytte sig automatisk, men destinationsoverskriften skal være synlig og ikke dækket af en sticky header.

Overskrifts-ID’er skal være unikke på siden og bør begynde med et bogstav. Hold dem med små bogstaver, med bindestreger, læsbare og fri for midlertidige datoer eller positionsnumre. Et stabilt ID kan forblive #verify-results, selvom den synlige overskrift forbedres fra “Verificér resultaterne” til “Verificér at den nye legitimationsoplysning virker.” Hvis sektionens betydning ændres fuldstændigt, opret et nyt ID og bevar det gamle fragment via et alias eller dokumenteret omdirigeringsadfærd, når platformen understøtter det. Den separate ankerlinks -specifikation styrer ankernavigation og interaktionsdetaljer.

Skriveregler

Skriv sidens oversigt, før du polerer individuelle etiketter. Hver overskrift skal besvare “hvad vil jeg lære, beslutte eller gøre her?” i konkret sprog. Foretræk “Sammenlign årlige og månedlige faktureringsomkostninger” frem for “Prisovervejelser,” og “Hvorfor importen afviser dublet-ID’er” frem for “Fejlfinding.” Beskrivende betyder ikke ordrigt; det betyder, at etiketten forudsiger sektionens faktiske indhold.

Brug én H1 på 20–80 tegn. Foretræk H2- og H3-overskrifter på 2–12 ord og højst 90 tegn. En lang guide har normalt 3–12 H2-sektioner. En H2 har brug for mindst én omfangs- eller svarsætning før eventuel H3. Brug to eller flere H3-sektioner under en overordnet, når underopdeling hjælper; en enkelt H3 signalerer ofte, at dens indhold bør flettes ind i H2.

Brug sætningsform, medmindre et proprium eller produktnavn kræver store bogstaver. Spørgsmål er passende, når sektionen besvarer det nøjagtige spørgsmål med det samme. Deklarative etiketter passer til faser, kriterier, resultater og specifikationer. Hold parallelle sektioner grammatisk parallelle: brug udsagnsord til en processekvens, navneord til sammenligningskriterier eller spørgsmål til et FAQ-sæt.

Undlad aldrig at inkludere disse i overskriftstekst:

• Markdown-links eller rå URL’er; de skaber konkurrerende destinationer og ustabile tilgængelige navne.
• Fodnotemarkører eller kildecitationer; placer evidens i det ejede indhold.
• Emoji brugt som strukturelle etiketter, statusmærker eller dekorative præfikser.
• Manuel nummerering, medmindre indlægstypen definerer en stabil ordnet sekvens.
• CTA-sprog som “Køb nu,” prispåstande, haster eller promotionsmærker.
• Stylinginstruktioner, HTML-linjeskift eller enhedsspecifikke forkortelser.
• En anden sætning, der hører til i afsnittet nedenfor.

Skriv ikke kloge etiketter, der afhænger af omgivende tekst for at give mening. “Nu tilspidser historien” kan passe til et essays tone, men det giver et søgeresultat, en indholdsfortegnelse, en skærmlæseroverskriftsliste eller en AI-citation ingen brugbar kontekst. Bevar personlighed i forklaringen efter en præcis overskrift.

Indlægstyper der bruger det

Front matter-arrayet postTypes driver disse relationer. Hver listede indlægstype bruger den samme hierarkikontrakt, mens dens egen anatomi bestemmer de nøjagtige sektionsnavne og rækkefølge.

QA-tjekliste

• Siden gengiver præcis én synlig H1, og den navngiver sidens faktiske emne.
• Oversigten går fra H1 til H2 til H3 uden sprangte niveauer.
• Hver H3 har én klar foregående H2-forælder.
• Hver overskrift efterfølges af meningsfuldt ejet indhold før næste overskrift.
• Hver H2 inkluderer en orienterende eller svarsætning før sin første H3.
• Overskriftstekst er beskrivende, når den læses alene i en indholdsfortegnelse eller skærmlæseroverskriftsliste.
• Parallelle sektioner bruger parallel grammatik og tilsvarende niveauer.
• Overskriftsniveauer afspejler relationer, ikke skriftstørrelse eller ønsket visuel vægt.
• Typificerede formål bruger stadig deres påkrævede elementer; overskrifter imiterer ikke komponenter.
• Hver offentliggjort overskrift har ét unikt, læseligt, stabilt fragment-ID.
• Eksisterende fragment-ID’er forbliver uændrede, når synlig ordlyd redigeres uden at ændre sektionens betydning.
• Direkte fragmentnavigation efterlader destinationen synlig under eventuel sticky header.
• Overskriftstekst indeholder ingen links, citationer, emoji-etiketter, promotionsmærker eller manuelle linjeskift.
• HTML-oversigten forbliver sammenhængende med menuer, kort, accordions, modaler og andre sidekomponenter til stede.
• Den gengivne side fungerer ved smal bredde, med overskrifter på to linjer, der ombrydes uden beskæring eller overlapning.

Afvis siden, når det visuelle design ser poleret ud, men oversigten fejler. Overskriftsfejl hober sig op: ét sprunget niveau eller én tom sektion får alle downstream-forbrugere til at arbejde hårdere for at rekonstruere relationer, som kilden burde have angivet direkte.

FAQ

Spørgsmålene nedenfor løser de tilfælde, der mest sandsynligt skaber uensartede oversigter på tværs af redaktører og platforme. Deres autoritative værdier findes i den strukturerede [[faq]]-front matter herover, så synligt output og eventuelt berettiget skemaoutput kan dele én kilde.