Rubrikstruktur: Regler för H1, H2 och H3

Ett rubriksystem är den ordnade uppsättningen av en sidtitel och dess avsnittsetiketter. Det förvandlar en lång sida till en läsbar väg för människor och en maskinläsbar disposition för sökmotorer, hjälpmedelsteknik och AI-svarssystem.

Sidtiteln ovan är denna sidas enda H1. Varje större specifikation nedan är en H2, och varje underindelning inom ett större avsnitt är en H3. Den levande dispositionen är det renderade elementet: dess nivåer uttrycker relationer snarare än teckenstorlekar.

Varför detta element är viktigt

Läsare konsumerar sällan en lång sida i ett enda oavbrutet pass. De skannar efter en igenkännbar fråga, jämför avsnittsetiketter med sitt aktuella behov och bestämmer var de ska sakta ner. Beskrivande rubriker minskar den ansträngningen eftersom var och en ger ett litet löfte om vad som följer. “Hur stabila rubrik-ID:n bevarar citat” är användbart vid en blick; “Några fler tankar” är det inte.

Samma hierarki stödjer maskinextraherbarhet, vilket innebär att ett automatiserat system kan identifiera ett avsnitt, förstå hur det relaterar till sidans ämne och hämta det utan att förväxla det med ett närliggande avsnitt. H1 etablerar sidans ämne. H2 delar upp ämnet i primära frågor. H3 smalnar av en H2 till en metod, ett fall, ett kriterium eller ett undantag. En hoppad nivå döljer den relationen och tvingar en parser att sluta sig till om ett underavsnitt är ett syskon, ett barn eller ett orelaterat block.

Rubriker skapar också adresserbara avsnitt. Ett fragmentidentifierare är den del av en URL efter #, såsom #qa-checklist. Sökresultat, interna länkar, webbläsarbokmärken och AI-svar kan peka till just den destinationen. Ett slumpmässigt omdöpt automatiskt genererat ID kan därför bryta en URL även när sidan i sig fortfarande finns. Rubriken är inte dekoration: dess text definierar avsnittet och dess ID blir en beständig publik adress.

Följ skrivreglerna för element när ett avsnitts syfte matchar ett typat element. En H2 som heter “Varning” ersätter inte en varningsruta, och en H2 som heter “Jämförelse” ersätter inte en jämförelsetabell. Rubriker ger dokumenthierarki; typade element ger ändamålsspecifik struktur. Båda kan behövas.

När det ska användas

Använd rubriksystemet på varje meningsfull indexerbar sida. Även en kort sida behöver en H1. Lägg till H2-avsnitt när läsaren måste röra sig mellan distinkta frågor, stadier, kriterier eller bevisgrupper. Lägg till H3-underavsnitt endast när en H2 innehåller minst två genuint distinkta delar som drar nytta av separat navigering.

Nära-missarna är visuella etiketter som ser ut som rubriker men inte hör hemma i artikeldispositionen:

• En korttitel namnger ett upprepat kort; det är inte automatiskt ett dokumentavsnitt.
• En utropningsetikett som “Tips” eller “Viktigt” identifierar rutan typ; det blir inte en H2 bara för att den är fetstilt.
• En diagramtitel identifierar en figur. Den hör hemma i figurens bildtext eller tillgängliga namn om inte diagrammet inleder ett helt avsnitt.
• En navigeringsmenyetikett, brödsmula, flik, accordion-kontroll, sidfotsrubrik och modaltitel kan behöva komponentsemantik, men de ingår inte i den huvudsakliga artikelhierarkin.
• En stor reklamslogan är presentationskopia. Teckenstorlek kan inte uppgradera den till dokumentets H1.

Lägg inte till en rubrik enbart för att introducera en mening, dela upp en löpande förklaring eller skapa visuellt andrum. Använd styckeavstånd eller redigering för sådana uppgifter. En användbar rubrik markerar ett avsnitt som är tillräckligt omfattande för att besvara ett distinkt läsarbehov.

Var rubriker ska placeras

Position uttrycker härstamning. Placera H1 i början av huvudinnehållet, efter brödsmulor eller annan webbplatsnavigering och före introduktionen. Placera varje H2 före ett primärt avsnitt. Placera en H3 endast efter dess överordnade H2 och den överordnades orienterande innehåll, aldrig före den första H2 och aldrig som ett syskon valt för visuellt utseende.

Två rubriker får inte vara angränsande i redigerat artikelinnehåll. Varje rubrik måste äga användbart innehåll före nästa rubrik på samma eller djupare nivå. Denna regel förhindrar tomma avsnittsetiketter, ger läsare sammanhang före en underavsnittslista och skapar extraherbara passager snarare än en bar disposition.

Anatomi

Den märkta anatomins fem delar:

1. H1: det unika sidämnet och toppen av innehållsdispositionen.
2. H2: en primär fråga, fas eller dimension inom det ämnet.
3. H3: ett underämne som inte kan förstås korrekt utan sin överordnade H2.
4. Ägt innehåll: svaret, bevisen, instruktionerna eller förklaringen mellan en rubrik och nästa rubrik på samma eller högre nivå.
5. Stabilt ID: fragmentdestinationen kopplad till rubriken och bevarad efter publicering.

Relationen förblir giltig om typografin ändras. Ett tema kan rendera H2 med mindre teckenstorlek på mobil, men den måste förbli H2 i HTML. Omvänt, att göra en paragraf stor och fetstilt ger den inte rubriksemantik eller en fragmentdestination.

Designexempel

Designvarianter motsvarar semantiska nivåer och verkliga omslutningstillstånd, inte godtyckliga färgalternativ.

H1-sidtitel: visa det unika ämnet i början av huvudinnehållet. En stödjande beskrivning kan följa, men ingen ögonbrynstext, logotyp eller hjälteslogan blir ytterligare en H1.

H2 primärt avsnitt: gör avsnittet förståeligt från en innehållsförteckning och följ med innehåll som etablerar omfattning.

H3-underavsnitt: använd den mindre nivån eftersom ämnet är underordnat, inte för att designern vill ha mindre text.

Bruten rubrik: tillåt en naturlig tvåradig brytning på smala skärmar. Förkorta inte en tydlig rubrik till en tvetydig etikett enbart för att hålla den på en rad.

Förankrade tillstånd: visa hovring och tangentbordsfokus utan att göra ankaret till det enda sättet att förstå destinationen. Direktnavigering måste kompensera för eventuell sticky header så att rubriken inte är dold.

Parametrar

Rubriksystemet är ett dokumentkontrakt snarare än en dekorativ komponent. Dess parametrar definierar dispositionen, texten läsarna ser, innehållet varje nod äger och den URL med vilken noden kan nås.

Tecken- och ordgränserna är redaktionella band, inte skäl att utelämna nödvändig specificitet. En rubrik på 94 tecken som skiljer två liknande procedurer åt är bättre än en kort men missvisande. De strukturella gränserna är strikta: en H1, inga hoppade nivåer, inga dubletterade ID:n och inga tomma avsnitt.

Syntax och kodexempel

Den kanoniska portabla formen omsluter den ursprungliga dispositionen i en heading-system-direktiv. Den första rubriken mappas till dokumenttiteln; senare rubriker förblir ordnade innehållsnoder. Explicita ID:n läggs till när rubrikerna blir offentliga.

Bärbart Markdown-direktiv

:::heading-system
# Rotera en API-nyckel utan driftstopp

Ersätt referensen i varje beroende tjänst innan du återkallar den gamla nyckeln.

## Förbered ersättningen

Registrera varje tjänst som för närvarande läser referensen.

### Identifiera dolda användare

Kontrollera schemalagda jobb, distributionshemligheter och lokala integrationer.

## Verifiera och återkalla

Testa ersättningen, återkalla sedan den exponerade nyckeln.
:::

Vid publicering, lås stabila ID:n istället för att tillåta framtida textredigeringar att återskapa dem:

## Förbered ersättningen {#prepare-replacement}
### Identifiera dolda användare {#identify-hidden-consumers}

Hugo-shortcode

{{< heading-system h1="Rotera en API-nyckel utan driftstopp" >}}
## Förbered ersättningen {#prepare-replacement}

Registrera varje tjänst som för närvarande läser referensen.

### Identifiera dolda användare {#identify-hidden-consumers}

Kontrollera schemalagda jobb, distributionshemligheter och lokala integrationer.
{{< /heading-system >}}

Detta är Hugo-adapterkontraktet, inte ett påstående att detta register registrerar en heading-system-shortcode. En Hugo-implementering kan fortsätta att rendera H1 från frontmatter och brödtextrubriker via Markdown, som denna sida gör, förutsatt att den validerar samma hierarki och bevarar explicita ID:n.

WordPress-block

<!-- wp:heading {"level":2,"anchor":"prepare-replacement"} -->
<h2 id="prepare-replacement">Förbered ersättningen</h2>
<!-- /wp:heading -->

<p>Registrera varje tjänst som för närvarande läser referensen.</p>

<!-- wp:heading {"level":3,"anchor":"identify-hidden-consumers"} -->
<h3 id="identify-hidden-consumers">Identifiera dolda användare</h3>
<!-- /wp:heading -->

WordPress bör lagra H1 i sidtitelns fält eller godkänd hjälteblock, inte som ett andra rubrikblock i artikelkroppen. Ställ in varje publicerad rubriks HTML-ankare explicit så att en senare ordalydelseredigering inte tyst ändrar dess URL.

Exempel

Bra: dispositionen förutsäger fullständiga svar

# Hur du väljer ett arbetsflöde för faktura godkännande

## Definiera godkännanderisken
Förklara vilka fakturagränser, leverantörer och undantag som behöver granskning.

### Sätt värdetrösklar
Tilldela en namngiven godkännare till varje tröskel och dokumentera vad som händer vid gränsen.

### Hantera policyundantag
Skicka saknade inköpsorder och ändrade bankuppgifter till en separat granskningsväg.

## Testa arbetsflödet
Kör vanliga och exceptionella fakturor genom hela rutten före lansering.

Detta fungerar eftersom H1 anger en uppgift, varje H2 namnger ett primärt stadium, varje H3 tillhör sin förälder, och varje etikett följs av innehåll som uppfyller sitt löfte. En läsare kan skanna dispositionen och förutsäga var trösklar, undantag och testning täcks.

Dålig: styling ersätter hierarki

# Faktura godkännande

### Saker att tänka på
## Mer information
### Undantag
### Annat

Detta misslyckas av fyra oberoende skäl. Det hoppar från H1 till H3, använder etiketter som inte förutsäger ett svar, placerar rubriker bredvid varandra utan ägt innehåll och lämnar “Undantag” utan förklaring före nästa rubrik. Den resulterande dispositionen antyder täckning som sidan inte tillhandahåller. Den skapar också svaga automatiskt genererade ID:n som #other, som är tvetydiga när de citeras utanför sidan.

Schema-markup och tillgänglighet

Rubriker behöver inte en fristående Schema.org-typ. H1 tillhandahåller eller speglar vanligtvis headline för en Article, TechArticle eller annan lämplig sidentitet, men synlig ordalydelse och JSON-LD måste beskriva samma ämne. H2- och H3-avsnitt förblir HTML-struktur; skapa inte en schema-entitet för varje rubrik. En rubrik med titeln “Vanliga frågor” skapar inte heller FAQPage-markup av sig själv — den synliga frågor-och-svar-datan måste uppfylla FAQ-elementkontraktet.

Tillgänglighet beror på semantisk HTML och logisk ordning. Skärmläsaranvändare kan navigera via rubrik, inspektera en rubriklista eller hoppa direkt mellan avsnitt. Det arbetsflödet bryts när sidan hoppar nivåer för stylingens skull, använder fetstilta stycken som falska rubriker, eller inkluderar verktygs- och artikelrubriker i en osammanhängande hierarki.

Använd faktiska <h1>, <h2> och <h3>-element. Håll rubriktext synlig; en aria-label får inte ersätta tydlig text på skärmen. Ankarkontroller behöver ett beskrivande tillgängligt namn, synligt tangentbordsfokus och ett klickmål separat från rubriktexten när länkning av hela rubriken skulle förvirra urval. När en fragment-URL laddas behöver tangentbordsfokus inte flyttas automatiskt, men destinationsrubriken måste vara synlig och inte täckt av en sticky header.

Rubrik-ID:n måste vara unika inom sidan och bör börja med en bokstav. Håll dem gemener, avstavade, läsbara och fria från tillfälliga datum eller positionsnummer. Ett stabilt ID kan förbli #verify-results även om den synliga rubriken förbättras från “Verifiera resultaten” till “Verifiera att den nya referensen fungerar.” Om avsnittets innebörd förändras helt, skapa ett nytt ID och bevara det gamla fragmentet genom en alias eller dokumenterad omdirigeringsbeteende när plattformen stödjer det. Den separata ankarlänkar -specifikationen styr ankarnavigering och interaktionsdetaljer.

Skrivregler

Skriv sidans disposition innan du polerar enskilda etiketter. Varje rubrik bör besvara “vad kommer jag att lära mig, besluta om eller göra här?” i konkret språk. Föredra “Jämför årliga och månatliga faktureringskostnader” framför “Prisöverväganden,” och “Varför importen avvisar dubletter” framför “Felsökning.” Beskrivande betyder inte mångordigt; det betyder att etiketten förutsäger avsnittets faktiska innehåll.

Använd en H1 på 20–80 tecken. Föredra H2- och H3-rubriker på 2–12 ord och högst 90 tecken. En lång guide har normalt 3–12 H2-avsnitt. En H2 behöver minst en avgränsnings- eller svarsmening före någon H3. Använd två eller fler H3-avsnitt under en förälder när underindelning hjälper; en enda H3 signalerar ofta att dess innehåll bör slås ihop med H2.

Använd meningfall om inte ett egennamn eller produktnamn kräver versaler. Frågor är lämpliga när avsnittet besvarar den exakta frågan omedelbart. Påståendeetiketter passar stadier, kriterier, resultat och specifikationer. Håll parallella avsnitt grammatiskt parallella: använd verb för en processekvens, substantiv för jämförelsekriterier eller frågor för en FAQ-uppsättning.

Placera aldrig följande inuti rubriktext:

• Markdown-länkar eller råa URL:er; de skapar konkurrerande destinationer och instabila tillgängliga namn.
• Fotnotsmarkörer eller källhänvisningar; placera bevis i det ägda innehållet.
• Emoji som används som strukturella etiketter, statusmärken eller dekorativa prefix.
• Manuell numrering om inte inläggstypen definierar en stabil ordnad sekvens.
• CTA-språk som “Köp nu,” prisanspråk, brådskande uttryck eller reklammärken.
• Stylinginstruktioner, HTML-radbrytningar eller enhetsspecifika förkortningar.
• En andra mening som hör hemma i stycket nedanför.

Skriv inte fyndiga etiketter som är beroende av omgivande text för att vara begripliga. “Nu blir det intressant” kan passa en essäs röst, men det ger ett sökresultat, innehållsförteckning, skärmläsares rubriklista eller AI-citat ingen användbar kontext. Bevara personligheten i förklaringen efter en precis rubrik.

Inläggstyper som använder det

Frontmatters postTypes-array driver dessa relationer. Varje listad inläggstyp använder samma hierarkikontrakt, medan dess egen anatomi bestämmer exakta avsnittsnamn och ordning.

QA-checklista

• Sidan renderar exakt en synlig H1, och den namnger sidans faktiska ämne.
• Dispositionen går från H1 till H2 till H3 utan hoppade nivåer.
• Varje H3 har en tydlig föregående H2-förälder.
• Varje rubrik följs av meningsfullt ägt innehåll före nästa rubrik.
• Varje H2 innehåller en orienterande eller svarande mening före sin första H3.
• Rubriktext är beskrivande när den läses ensam i en innehållsförteckning eller skärmläsares rubriklista.
• Parallella avsnitt använder parallell grammatik och motsvarande nivåer.
• Rubriknivåer återspeglar relationer, inte teckenstorlek eller önskad visuell vikt.
• Typade syften använder fortfarande sina obligatoriska element; rubriker imiterar inte komponenter.
• Varje publicerad rubrik har ett unikt, läsbart, stabilt fragment-ID.
• Befintliga fragment-ID:n förblir oförändrade när synlig ordalydelse redigeras utan att ändra avsnittets innebörd.
• Direkt fragmentnavigering lämnar destinationen synlig under eventuell sticky header.
• Rubriktext innehåller inga länkar, citat, emoji-etiketter, reklammärken eller manuella radbrytningar.
• HTML-dispositionen förblir sammanhängande med menyer, kort, accordions, modaler och andra sidkomponenter närvarande.
• Den renderade sidan fungerar vid smal bredd, med tvåradiga rubriker som bryts utan beskärning eller överlappning.

Avvisa sidan när den visuella designen ser polerad ut men dispositionen misslyckas. Rubrikdefekter förvärras: en hoppad nivå eller tomt avsnitt gör att varje nedströms konsument måste arbeta hårdare för att rekonstruera relationer som källan borde ha angivit direkt.

FAQ

Frågorna nedan löser de fall som mest sannolikt skapar inkonsekventa dispositioner mellan redaktörer och plattformar. Deras auktoritativa värden finns i den strukturerade [[faq]]-frontmatter ovan så att synlig utdata och eventuell berättigad schemautdata kan dela en källa.