Utgiverveksttaktikker for valgsesongen | WEBINAR

Lær mer

SODP

SODP Media

  • Education
    • Articles
      • Audience Development
      • Content Strategy
      • Digital Publishing
      • Monetization
      • SEO
      • Digital Platforms & Tools
    • Opinion
    • Podcast
    • Events
      • SODP Dinner Event London 2025
      • SODP Dinner Event Dubai 2025
      • SODP Dinner Event California 2025
      • All Events
  • Top Tools & Reviews
  • Research & Resources
  • Community
    • Slack Channel
    • Newsletter
  • About
    • About Us
    • Contact Us
    • Editorial Policy
  • English
sodp logo
SODP logo
    Søk
    Lukk denne søkeboksen.
    Logg inn
    • Utdannelse
      • Podcast
      • Artikler
        • Publikumsutvikling
        • Innholdsstrategi
        • Digital publisering
        • Inntektsgenerering
        • SEO
        • Digitale plattformer og verktøy
        • Artikler
        • Mening
        • Podcaster
        • Hendelser
        • Publikumsutvikling
        • Innholdsstrategi
        • Digital publisering
        • Inntektsgenerering
        • SEO
        • Digitale plattformer og verktøy
        • Middagsarrangement i California 2025
        • PUBTECH2025
        • Vis alle
    • Toppverktøy og anmeldelser
        • Hodeløse CMS-plattformer
        • Digitale publiseringsplattformer
        • Programvare for redaksjonell kalender
        • Magasinapper
        • E-post nyhetsbrevplattformer
        • Flere lister over beste verktøy
        • Anmeldelser
    • Forskning og ressurser
    • Fellesskap
      • Slack Channel
      • Kontortid
      • Nyhetsbrev
        • Slack Channel
        • Nyhetsbrev
    • Om
      • Om oss
      • Kontakt oss
      • Redaksjonell politikk
        • Om oss
        • Kontakt oss
        • Redaksjonell politikk
    plassholder
    SODP logo
    Bli en merkevarepartner
    Hjem > Utgiver SEO-kurs > Kapittel 2: Teknisk SEO > Design og layout
    1

    Design og layout

    Design og layout
    Forrige kapittel
    Tilbake til kapittel
    Neste modul

    Læringsmål

    Etter å ha gått gjennom denne veiledningen, bør du være i stand til å forstå hvordan eksisterende nyhetsartikler endres og lages ved å bruke sidelayoutdesign som forbedrer Googles evne til å gjennomsøke og forstå sidens innhold.

    Videovarighet

    15:35

    Svar Quiz

    Ta gjeldende modulquiz

    Materialer

    Klar til bruk maler

    Ressurser

    Rapporter og ressurser

    Tidsbegrensning: 0

    Quizsammendrag

    0 av 9 spørsmål fullført

    Spørsmål:

    Informasjon

    Du har allerede fullført quizen før. Derfor kan du ikke starte den på nytt.

    Quizen lastes inn...

    Du må logge på eller registrere deg for å starte quizen.

    Du må først fullføre følgende:

    Resultater

    Quiz fullført. Resultatene blir registrert.

    Resultater

    0 av 9 spørsmål besvart riktig

    Din tid:

    Tiden har gått

    Du har nådd 0 av 0 poeng, ( 0 )

    Opptjente poeng: 0 av 0 , ( 0 )
    0 essay(er) venter (mulig(e): 0 )

    Kategorier

    1. Ikke kategorisert 0%
    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    9. 9
    1. Nåværende
    2. Gjennomgå
    3. Besvart
    4. Korrekt
    5. Uriktig
    1. Spørsmål 1 av 9
      1. Spørsmål

      Hva bør du unngå når du oppretter et nettsted?

      Korrekt
      Uriktig
    2. Spørsmål 2 av 9
      2. Spørsmål

      Hva bør du gjøre for å sikre at søkemotorer forstår innholdet på siden din?

      Korrekt
      Uriktig
    3. Spørsmål 3 av 9
      3. Spørsmål

      Hva bør du gjøre for å sikre at hver nyhetshistorie vises på en unik URL?

      Korrekt
      Uriktig
    4. Spørsmål 4 av 9
      4. Spørsmål

      Hva bør du gjøre for å forhindre unøyaktige artikkeltitler?

      Korrekt
      Uriktig
    5. Spørsmål 5 av 9
      5. Spørsmål

      Hva bør du unngå i artikler for å gjøre dem enklere for webcrawlers å lese?

      Korrekt
      Uriktig
    6. Spørsmål 6 av 9
      6. Spørsmål

      Hva er det grunnleggende markeringsspråket for nettsteder?

      Korrekt
      Uriktig
    7. Spørsmål 7 av 9
      7. Spørsmål

      Hva bør du gjøre for å sikre at siden din er enkel for webcrawlers å lese og forstå?

      Korrekt
      Uriktig
    8. Spørsmål 8 av 9
      8. Spørsmål

      Hva er den maksimale mengden sidedata GoogleBot kan laste ned i den første gjennomsøkingen?

      Korrekt
      Uriktig
    9. Spørsmål 9 av 9
      9. Spørsmål

      Hvilken type viderekobling skal brukes til ikke-permanente viderekoblinger?

      Korrekt
      Uriktig

    2.1.1 Hva er design og layout?

    Utformingen og utformingen av nettstedet ditt bestemmer hvordan det ser ut for sluttbrukeren. Dette er viktig fordi Google til syvende og sist er drevet av en bruker-først-filosofi. Nettsider som tilfredsstiller brukerens behov først, raskest og på enklest mulig måte belønnes med høyere SERP-rangeringer.

    Nettstedets design og layout bestemmer også hvor enkelt webcrawlere, for eksempel Google bot, gjennomsøker og indekserer det. Et enkelt og optimalisert design og layout betyr rask og enkel gjennomgang, som igjen gir bedre rangeringer.

    2.1.2 Utfordringer utgivere møter med design og layout

    Så hva stopper utgivere fra å implementere beste praksis for design og layout? Oftest blir utgivere konfrontert med disse smertepunktene:

    • Tvetydighet om hva resultater kan er gjennomførbart
    • Usikkerhet over krav til ferdigheter
    • Tvetydighet over ressursbehov

    2.1.3 Betyr design og layout noe for SEO?

    For å svare på dette spørsmålet utførte vi et enkelt Google-søk og skrev inn søkeordene «Charlie Puth News» i søkefeltet.

    Her er hva søkeresultatene viste:

    Betyr design og layout noe for SEO?

    På nummer to på Top Stories SERP-rangeringen, rett over en historie av NME, er Daily Illinis artikkel om Charlie Puths siste utgivelse.

    Det faktum at Daily Illini, en universitetsstudentavis, overgår verdens største frittstående musikknettsted, reiser noen viktige spørsmål

    Betyr design og layout noe for SEO?

    Hvordan klarer en studentavis i en by med rundt 40 000 innbyggere i det amerikanske midtvesten det største musikknyhetsnettstedet på jorden? Spennende bestemmer vi oss for å grave litt mer.

    Først sjekket vi ut NMEs side på Charlie Puth.

    Rett utenfor balltre, er det første vi legger merke til den popup-videoen som prøver å laste nederst til høyre på skjermen. Det gjør tydeligvis ikke en veldig god jobb med lasting. Den buffere videoen skjuler også en del av nyhetsoverskriften og dens kropp.

    Neste gang legger vi merke til at den første visningsporten mest er okkupert av ting som ikke er relevant for nyhetshistorien. Det er et stort bannerannonse som dekker omtrent halvparten av siden, og selvfølgelig er det videoen.

    Faktisk, bla nedover siden, møter vi flere videoer, mer store, rike bilder, flere popup-annonser og mange hyperkoblinger. Gitt hvor medie-rik siden er, tok den overraskende ganske lang tid å laste.

    Vi inspiserte deretter Daily Illini, og her er hva vi fant.

    Vi inspiserte deretter Daily Illini, og her er hva vi fant

    Siden er ryddig, ren og ryddig. Den har sin andel av annonser og en stor donasjonsknapp øverst, men det er ingen videoer eller popup-vinduer som dekker Viewport eller hindrer nyhetsoverskriften. Vi kan se overskriften med en gang, og det er veldig sannsynlig at det samme gjelder Googles webcrawler.

    I det store og hele er siden lett, minimalistisk og lynraskt å lastes.

    Vi bestemte oss for å kikke under panseret litt mer på den underliggende koden. Ved å høyreklikke på siden og velge Visekilde (mens vi bruker Chrome), kan vi se sidens kode.

    Dette er hva vi så for NME -siden:

    Dette er hva vi så for NME Page -kildekoden

    Dette er hva vi så for NME Page -kildekoden

    To ting fanget oppmerksomheten vår her:

    1. NME -koden spenner over 5.516 linjer, sammenlignet med Daily Illinis 1.481 linjer
    2. NMW bruker skript for å gjengi nøkkelelementer på en side - for eksempel brødsmuler - i stedet for å bruke HTML

    Dette er ikke det beste for en side av to grunner:

    1. Nettcrawlere har vært kjent for å møte problemer mens de implementerer skript
    2. Kode som er uvanlig kompleks kan redusere tolkningen og utførelsen.

    Da vi så på koden for Daily Illini -siden derimot, så vi dette:

    Da vi så på koden for den daglige Illini -siden derimot, så vi dette

    Dette er veldig enkel HTML -kode. Det er heller ingen skript som kjører innenfor<head> del.

    Hvordan legger alt dette opp til den daglige Illini Outranking NME?

    Det er sannsynligvis en rekke faktorer på jobb her, og en av dem er design og layout. Daily Illini -siden distribuerer visse design- og layout -teknikker som til og med små utgivere lett kan gjenskape for å øke deres generelle SEO -strategi.

    Disse inkluderer bruk av ren, enkel HTML-kode, unngår skript i overskriftsdelen, holder siden lett og raskt å laste, og ikke stole for tungt på popup-vinduer og mellomliggende annonser.

    Guiden nedenfor graver seg inn i hver enkelt av disse i detalj, mens du forklarer flere andre teknikker du kan implementere for å forbedre SERP -rangeringen betydelig.

    2.1.4 Introduksjon til semantisk HTML -markering

    Hva er semantisk HTML -markering?

    Semantikk forholder seg til betydningen av ord. Semantiske HTML -tagger er de som tydelig definerer betydningen både for leseren og en webcrawler.

    For eksempel når vi bruker en tag som<header> , vi vet hva den inneholder - informasjon om overskriften.

    Tilsvarende<h1> er en semantisk tag som forteller Googlebot at det som følger er den viktigste overskriften i artikkelen.

    Derimot, når vi bruker en tag som<div> , betydningen er ikke umiddelbart åpenbar. I HTML<div> Står for divisjon, og alt det tilsier er at en ny kodeseksjon har begynt, uten nødvendigvis å avsløre informasjon om innholdet i denne delen.

    Hvorfor er semantisk HTML viktig for teknisk SEO?

    Nettcrawlere som GoogleBot er bygget ved hjelp av kunstig intelligens og maskinlæringsalgoritmer som prøver å simulere funksjonen til den menneskelige hjernen. Dette betyr at de gir mening om tekst på omtrent samme måte som den menneskelige hjernen gjør.

    HTML -kode som er lett for mennesker å forstå, bør også være enkelt for Googles webcrawler å forstå.

    Som et eksempel, bør du vurdere de to delene av HTML -kode nedenfor:

    Hvorfor er semantisk HTML viktig for teknisk SEO?

    Kilde: https://www.pluralsight.com/guides/semantic-html

    Denne siden bruker<div> Merk for alt, fra overskrift til hovedinnholdet til bunnteksten. Det er ikke umiddelbart tydelig ved å lese taggene hva innholdet er.

    Derimot bruker siden nedenfor semantisk markering. Overskriften er plassert i<header> Tag, bunntekst i<footer> Tag, og hoveddelen av artikkelen går innenfor<main> tag.

    Hvorfor er semantisk HTML viktig for teknisk SEO?

    Kilde: https://www.pluralsight.com/guides/semantic-html

    Siden dette er enkelt for Googlebot å lese og forstå, har denne siden en bedre sjanse til å rangere høyere enn den forrige, alle andre ting er like.

    For å se om siden din bruker semantisk markering, høyreklikk bare på siden hvis du bruker Google Chrome, og klikk på Inspiser. Du vil kunne se HTML -kildekoden på siden. Vanlige semantiske elementer inkluderer<author> ,<video> ,<article> ,<form> ,<header> , etc.

    Vi vet nå hva semantisk markering er og hvorfor det er viktig. Men hvordan bruker vi den til å forbedre SEO?

    Det er enkelt - bruk alltid semantisk markering for å markere viktig informasjon om artikkelen din design og utforming. Dette inkluderer følgende artikkelinformasjon:

    • Overskrift
    • Overskrifter
    • Avsnitt
    • Bilde alt tekst.

    Forsikre deg om at sideoppsettet ditt er velordnet for å forbedre krypingen

    2.1.5 Grunnleggende om design og layout

    Du designer nettstedet ditt for å bli lest av både mennesker og webcrawlere, og som sådan skal designet og utformingen din gjenspeile dette faktum.

    Nedenfor er noen tips for å hjelpe deg med å oppnå målbare resultater for nettstedet ditt.

    Bruk vanlig HTML når du lager artikler

    Du kan bruke HTML, CSS, JavaScript eller noe annet frontendspråk for å lage rike og interaktive sider. Husk imidlertid at jo mer avansert språket, desto større er dets kompleksitet, og jo større sjanser er at en webcrawler kan synes det er vanskelig å lese, tolke og kompilere.

    Alt som er kodet i HTML er kanskje ikke det peneste å se på, men det vil både laste raskere og være mer optimalisert for søkemotorer av den enkle grunnen som søkemotorer kan lese og forstå det raskere.

    Tenk på vanlig HTML som bare beinskjelettet på websiden din. Du kan legge til CSS og JavaScript for å kaste det ut og få den til å se estetisk tiltalende og dynamisk ut, men det ville være bedre å holde det viktigste innholdet i skjelettet i stedet for å plassere det i kjøttet.

    Så hvordan implementerer vi vanlig HTML? En enkel måte å gjøre det på er å plassere hoveddelen av innholdet ditt i<article> HTML -tagger.

    På denne måten, når webcrawlere møter<article> Tag, de vet umiddelbart at det som følger er det viktigste innholdet på siden din - nyhetsartikkelen. Dette hjelper søkemotoren til å forstå at innholdet som er pakket inn i denne taggen, må tildeles større vekt.

    Vanlige HTML -er<article> Tag er en semantisk markør som ser slik ut:

    Plain HTMLs artikkelmerke er en semantisk markør som ser slik ut

    Kilde: https://en.wikipedia.org/wiki/article_element

    Det neste åpenbare spørsmålet? Hvis jeg bruker en CMS som WordPress, hvor setter jeg inn disse taggene?

    Slik gjør du dette: Hvis du bygger et tilpasset nettsted ved hjelp av HTML, kan du sjekke kildekoden for å sikre at den bruker vanlig HTML, spesielt i kritiske områder. Vi vil anbefale å snakke mer detaljert med en utvikler for å sikre at du ikke hamstrer funksjonalitet ved et uhell.

    Hvis du bruker WordPress, kan du se denne guiden . Du kan også finne denne guiden for hvordan du setter inn HTML i innlegg og sider en nyttig referansekilde.

    Disse instruksjonene er for WordPress, da WordPress er fortsatt den mest populære CMS for utgivere. Hvis du bruker en annen CMS som WIX, kan du ta kontakt med støtte- eller dokumentasjonssiden for CMS.

    Hvis du har tilgang til et team av nettutviklere, er det best å få dem til å gjøre det, da å redigere HTML -kode kan være tidkrevende.

    Testinnhold på tvers av plattformer

    Test for å sikre at innholdet ditt vises riktig i alle nettlesere, enheter og størrelser. Denne er mer åpenbar, men ofte oversett. Hvis innholdet ditt ikke vises slik du vil ha det på alle nettlesere og enheter, vil det påvirke brukeropplevelsen, og på lang sikt, SERP -rangeringene dine.

    Slik gjør du dette: For å teste innhold på tvers av plattformer må du åpne siden din i forskjellige enheter og i forskjellige nettlesere for å se hvordan den blir gjengitt.

    På et minimum bør du teste for følgende:

    1. Åpne siden på en stasjonær/bærbar PC for å se om designen og oppsettet er slik du hadde tenkt at de skulle være.
    2. Enten åpne siden i en mobil enhet for å se om alle elementene på siden blir gjengitt riktig eller bruker Googles Chrome DevTools for å simulere en mobil enhet .
    3. Åpne siden i flere nettlesere - Google Chrome, Mozilla Firefox og Microsoft Edge - for å se at den lastes riktig og jevnt.

    Bruk strukturerte data

    HTML -markeringer er med på å fremheve de forskjellige elementene på siden din. Strukturerte data hjelper søkemotorer med å lese hva som er i de forskjellige elementene på siden din og bedre forstå innholdet.

    Strukturerte data er ganske enkelt en serie instruksjoner skrevet på et enkelt språk, for eksempel JSON-LD, som kan settes inn i den eksisterende HTML-koden på websiden din. Tenk på det som en metabeskrivelse, men for individuelle innholdsdeler på siden din.

    I eksemplet nedenfor hjelper strukturerte data Google med å identifisere fem attributter om en DBPedia -side på John Lennon:

    • Kontekst: Siden handler om en person.
    • ID: Hvor på internett er siden som ligger. I dette tilfellet er det dbpedia.org
    • Navn: Hva heter personen som er gjenstand for denne siden? I dette tilfellet er det John Lennon.
    • Født: Når ble denne personen født?
    • Ektefelle: Hva heter ektefellen deres?

    Bruk strukturerte data

    Kilde: https://json-ld.org/

    Som du kan se, er koden på enkelt språk som er lett for både en menneskelig leser og en webcrawler å forstå.

    Her er et annet eksempel som viser hvordan strukturerte data kan passe rett inn i websiden din eksisterende HTML -kode. De strukturerte datainstruksjonene blir fremhevet i grønt.

    Bruk strukturerte data

    Kilde: utviklere.google.com

    I dette eksemplet forteller Structured Data til GoogleBot at dette er en oppskriftsside om kaffekake fra noen som heter Mary Stone.

    Ved å bruke strukturerte data i nettstedets oppsett leverer målbare utfall. For eksempel kan bruk av strukturerte data øke nettstedets klikkfrekvens (CTR) med opptil 30%.

    Å bruke strukturerte data hjelper også siden din rangering bedre på Googles karuseller, med utdrag, videoer og kunnskapspanelfunksjoner.

    For Google News SEO er det viktig å inkludere følgende elementer når du oppretter strukturerte data for å gi merverdi:

    • DatoPublisert: Dato da nyhetene først ble publisert ved hjelp av ISO 8601 -format.
    • Datemodifisert: Dato da den sist ble endret eller oppdatert.
    • Overskrift: Ikke overskrid 110 tegn.
    • Bilde: En lenke til bildet som følger med artikkelen. Bildet skal merkes ved hjelp av HTML -tagger.
    • ISAccessible Forfreefree: Dette feltet indikerer om nyhetene står bak en lønnsvegg eller ikke.
    • forfatter.url: Inkluder en lenke til biografen eller profilen til artikkelenes forfatter. Det er god praksis å også inkludere forfatterens sosiale mediehåndtak i biografen.

    Slik gjør du dette: Du kan legge til strukturerte data/skjema i innholdet ditt enten manuelt eller ved å bruke en plugin for akkurat CMS.

    1. Begynn med å legge inn sidens URL i Googles strukturerte datatestingsverktøy . Dette vil fortelle deg om du allerede bruker strukturerte data, og i så fall hvor på siden din er lokalisert. Dette gir deg igjen en ide om hva slags strukturerte data du fremdeles trenger å legge til og hvor.
    2. Hvis du planlegger å legge til strukturerte data manuelt, må du ha en grunnleggende forståelse av Schema.org. Dette er en god ressurs å lære mer om schema.org. Hvis du ikke er komfortabel med å redigere HTML -koden på siden din, anbefaler vi å få hjelp av en nettutvikler.
    3. Hvis du bruker en CMS som WordPress, kan det hende at du ikke kan redigere HTML -koden direkte. I dette tilfellet er det mer praktisk å bruke en plug-in som Schema Pro , Schema App strukturerte data eller andre gode WordPress-plug-in. Hvis du bruker andre CMS som WIX, kan du se etter riktig plugin-modus. Merk: Vennligst ta kontakt med din hostingleverandør for å unngå potensielle plug-in-konflikter.

    Strukturer innholdet ditt

    Alle elementene i nyhetsartikkelen din skal ordnes i en bestemt rekkefølge for å tillate raskere og enklere kryping. Bestillingen er som følger:

    • Overskrift
    • Bilde (med alternativ tekst)
    • Forfatterbiografi og dato
    • Artikkellegeme

    Sideopplevelse

    Sideopplevelse er et mål på hvordan brukere opplever siden din. Google har et sett med parametere for å kvantifisere sideopplevelse. Vi har viet en hel modul til sideopplevelsesfaktorer , så vi vil bare kort se på hver her.

    • Core Web Vitals (CWV): CWV er en Google -metrikk som måler tre ting - hvor raskt nettstedet ditt lastes inn, hvor interaktivt det er og hvor visuelt stabilt det er. Dette gjøres ved hjelp av tre andre beregninger - største innholdsmaling (LCP), første inngangsforsinkelse (FID) og kumulativt layoutskift (CLS).
    • Mobil vennlighet: Nettstedet ditt skal være lydhør overfor mobile enheter.
    • HTTPS -ordning: HTTPS er den sikre versjonen av HTTP som brukes til å overføre data over Internett. HTTPS krypterer data sendt over et nettverk og sikrer ekthet og personvern.
    • Ingen påtrengende interstitials: Interstitials er popup-vinduer som annonser eller dialogbokser som dekker en betydelig del av brukerens skjerm, og dermed forstyrrer visningsopplevelsen. Påtrengende interstitials gjør det også vanskelig for Google å forstå innholdet på siden.

    Slik gjør du dette: Du kan teste sideopplevelse både manuelt og ved å bruke plugins eller tredjepartsapper. For eksempel sidehastighetsinnsikt et praktisk verktøy som hjelper deg å analysere nettstedets ytelse basert på CWV og andre parametere og tilordner en poengsum basert på analysen. Den tester også for både mobil og skrivebords respons.

    Unike og permanente nettadresser

    Nyhetsutgivere skal ikke publisere flere nyhetsartikler under samme nettadress. Dette vil hindre Google fra å indeksere dem. Hver nyhetsartikkel skal ha sin egen unike URL.

    Videre bør disse nettadressene være permanente. Noe som betyr at den samme nyhetshistorien skal vises på en bestemt URL. Hvis nyhetshistorien knyttet til en bestemt URL -en endres ofte, vil Google ikke kunne krype og indeksere den. Utgivere bør imidlertid oppdatere nyhetshistorien så ofte som trengs.

    URL -viderekoblinger

    Hvis viderekoblinger må brukes til nyhetsartikler, bør de implementeres i henhold til følgende beste praksis:

    • Bruk så få viderekoblinger som mulig for å koble fra en side til en annen
    • Forsikre deg om at du omdirigerer til en gyldig side
    • Hvis du bruker en viderekoblingstimer som omdirigerer en bruker til en annen side etter at en viss tid er gått, må du forsikre deg om at du minimerer dette vinduet
    • Forsikre deg om at en side ikke omdirigerer for seg selv
    • For permanente viderekoblinger, bruk en omdirigering av 301
    • Unngå å bruke & ID = som en URL -parameter

    2.1.6 Hyggelig å ha

    Selv om handlingselementene som er oppført i denne delen ikke er like viktige som de ovenfor, anbefaler vi fortsatt å implementere så mange av disse som mulig når de oppdragskritiske punktene som er oppført ovenfor er blitt adressert.

    Rengjøre<head> Kode

    De<head> Element på en side inneholder viktig informasjon om siden som faktisk ikke vises på siden. Det det inkluderer er metadata som hjelper Googlebot med å identifisere innholdet på siden og klassifisere det.

    Som regel, den<head> Elementet skal bare inneholde de viktigste taggene og ingenting annet, slik at et innlegg kan krypes og gjengis ordentlig. Disse inkluderer:

    • tittel
    • <style>
    • <meta>
    • <link>
    • <script>
    • <base>

    Noe annet som er inneholdt i<head> Element vil sannsynligvis forvirre nettcrawlere.

    For eksempel er det vanlig at nybegynnere forveksler titteltaggen med<h1> og plasser sistnevnte innenfor<head> elementet. Som tidligere forklart,<head> Elementet kan bare inneholde metadata som ikke vises på siden.

    Selv om tittel og<h1> bør i hovedsak inneholde den samme informasjonen, førstnevnte er metadata ment for webcrawlere og som skal vises i SERP-resultatene og nettleserfanen, mens sistnevnte er informasjon som skal vises på siden.

    Koden nedenfor viser hvordan du plasserer tittelen i<head> element.

    Kilde: utvikler.mozilla.org

    Opprette en brukervennlig UX

    Å bruke sideelementer som gjør det enkelt å skanne innhold og gjøre navigasjon til en friksjonsfri opplevelse for brukeren, påvirker også SEO.

    En enkel å navigere siden vil inneholde disse elementene:

    • Hjemmeside
    • Meny
    • Søk
    • Kategorisider
    • Nyhetsartikkel sider
    • Registrer deg/abonner

    Med mindre du er en erfaren nettutvikler, er det best å konsultere en ekspert på den beste måten å implementere en brukervennlig UX.

    Skape en god annonseopplevelse

    Google ønsker at utgivere skal vise annonser uten å forstyrre brukerens opplevelse. Av denne grunn kan det straffe nettsteder som viser for mange påtrengende annonser. Mens brukeropplevelse er en subjektiv beregning, har Google visse retningslinjer og beste praksis når det gjelder annonser.

    Noen av dem forholder seg til:

    • Annonseplassering: Forsikre deg om at siden din ikke er tung med annonser
    • Annonseinnhold: Sørg for at annonsene dine ikke er støtende eller upassende
    • Annons til innholdsforhold: Å holde dette forholdet ikke høyere enn 30%
    • Unngå påtrengende interstitials: Unngå annonser som pop-up og dekker en betydelig del av brukerens skjerm.

    For mer informasjon om annonser og popups, se vår detaljerte modul .

    2.1.7 Unngå disse vanlige fallgruvene

    Ikke bruk JavaScript når du lager artikler

    JavaScript er flott for å lage dynamisk og interaktivt innhold, men webcrawlers kan oppleve vanskeligheter med å gjengi det.

    Dette er fordi:

    • JavaScript er vanligvis gjengitt på klientsiden i stedet for på serveren. Som en generell regel blir alt som er gjengitt på serversiden vanligvis utført raskere.
    • GoogleBot bruker en totrinns indekseringsprosess der den indekserer HTML-innholdet på en side i den første bølgen, og JavaScript i den andre bølgen. Dette kan ikke bare forsinke indeksering, men kan noen ganger til og med resultere i at JavaScript -innholdet blir savnet av Googlebot helt.
      Så selv om dette ikke betyr at du ikke skal bruke JavaScript i det hele tatt på siden din, er det bare å sørge for at artikkelseksjonen er gratis fra JavaScript.

    Unngå artikkelavbrudd

    Med nyhetsartikler er det god praksis å unngå avbrudd som relaterte artikkelkaruseller eller bildegallerier.

    Overvåk nettstedet ditt etter redesign

    Mange utgivere som gjør det bra blir bekymret når de relanserer/redesigner nettstedet sitt, da det krever at Google rekrutterer nettstedet. Følg disse beste praksisene for å sikre en jevn overgang til normal etter redesign/relansering:

    • Forsikre deg om at alle sidene dine er tilgjengelige med Googles webcrawler ved å legge inn nettadressene til Googles URL -inspeksjonsverktøy
    • Hvis du ikke vil at Google skal krype visse sider, blokkerer du tilgang til dem ved å bruke roboter.txt eller noindex -tagger
    • Oppdater nettstedskartet ditt. Dette forteller Google hvilke sider på nettstedet ditt som må kveres og indekseres
    • Hvis du har endret strukturen på nettstedet ditt under redesign, kan du oppdatere postene som er tilknyttet websidene dine med Googles Publisher Center . For mer informasjon om Google Publisher Center, se vår detaljerte kursmodul .

    Unngå tungvekt HTML på artikkelsider

    Hold artikkelsidene så lette som mulig. Vi har allerede sett på å unngå JavaScript i artikler, men det er også god praksis å unngå å bruke tungt HTML -innhold.

    Dette er fordi når GoogleBot kryper siden din, kan den bare laste ned maksimalt 15 MB sidedata i den første gjennomsøkingen. For de fleste sider er dette ikke et stort problem da tunge vektelementer som videoer og bilder refereres til separat innenfor koden som GoogleBot indekserer senere, og dermed er utenfor formålet med denne 15 MB -grensen.

    Dette peker imidlertid igjen på at jo lettere siden din, jo lettere vil det være for Googlebot å krype og indeksere den.

    Tips: Hvis du vil sjekke størrelsen på siden din, gå til nettleserens utviklerverktøy -side, bytt til nettverksfanen, og legg deretter last på siden. Dette viser alle forespørslene nettleseren din har gjort om å gjengi siden fullt ut. Den første forespørselen på denne listen viser størrelsen på siden din under størrelseskolonnen. For de fleste sider på internett er dette tallet vanligvis i kilobyte.

    Fix feil artikkelutdrag

    Artikkelutdrag gir leserne en forhåndsvisning av innholdet på siden før de klikker på det. Google bestemmer utdraget for å følge med hver artikkel ved å krype teksten i hoveddelen av artikkelen rett under tittelen.

    For å unngå muligheten for GoogleBot inkludert feil utdrag, sørg for at:

    • I sidens HTML -kode er det ikke plassert noen tilleggstekst mellom tittelen og hoveddelen.
    • Forfatterbylinjer, forfatter BIOS og artikkelpublikasjonsdato er tydelig differensiert fra begynnelsen av hoveddelen av artikkelen. For beste praksis for hvordan du implementerer dette, se retningslinjer for strukturerte data og semantisk markering diskutert tidligere.

    Forhindre manglende eller uriktige bilder

    Noen ganger kan GoogleBot enten unnlate å indeksere bildet ditt eller indeksere et annet bilde enn det du hadde tenkt å inneholde med artikkelen din. For å unngå dette, følg disse beste praksisene:

    • Bruk skjema -markering for å hjelpe GoogleBot bedre med å identifisere bildene dine. Schema.org inneholder semantisk markeringskode som kan hjelpe GoogleBot bedre å identifisere bildet ditt. OpenGraph (OG) er et annet verktøy som brukes til et lignende formål. Schema.org Strukturerte data stammer fra et samarbeid mellom de store søkemotorene - Google, Yahoo!, Bing og Yandex - for å gjøre identifisering og indekseringselementer på en side enda mer nøyaktig og enkelt.
    • Bruk bare bildeformater som Google støtter som JPEG, GIF, PNG, BMP, Webp og SVG. Forsikre deg også om at bildene er minst 90 x 60 piksler i størrelse.
    • Vær forsiktig når du inlinerer bilder. Det er to måter å inkludere bilder i koden din - inline eller referanse til en ekstern kilde. Når du bruker et inline -bilde, reduserer det antall ganger webcrawleren må følge en ekstern lenke og dermed redusere gjennomgangstiden. Imidlertid har innfyllende bilder ulempen med å øke sidestørrelsen. Det er således en avveining involvert mellom inlining og referanser, og det beste kurset å følge vil bli avgjort av dine prioriteringer. Hvis bildene dine ikke er for tunge, må du formatere dem inline.
    • Forsikre deg om at det kjente bildet ditt er plassert nær tittelen på artikkelen og at tilgangen til bildet ikke er blokkert av en robot.txt -tag eller metadata

    Forhindre unøyaktige artikkeltitler

    GoogleBot bruker artikkelen til artikkelen din for å identifisere og indeksere den riktig. Bruk disse følgende beste praksis for å sikre at den leser tittelen nøyaktig:

    • Sørg for at innholdet i tittelen og<h1> taggen til artikkelen din er den samme
    • Unngå å sette inn hyperkoblinger i artikkelens tittel
    • Forsøk å unngå å bruke en dato eller tid i artikkelen din tittel
    • Hvis du kobler artikkelen din til en annen del av nettstedet ditt, må du sørge for at ankerteksten som lenker til artikkelen din er den samme som tittelen på artikkelen

    2.1.8 Eksempler på nettsteder gjort bra

    La oss se på to casestudier av nettsteder som allerede har implementert trinnene som er omtalt i denne artikkelen.

    Moderne nyhetsnettsteder er sammensatte og rike, og det vil være urealistisk å forvente at de følger disse retningslinjene strengt. I dette avsnittet prøver vi imidlertid å demonstrere hvordan det å følge retningslinjene kan resultere i forutsigbare, målbare utfall.

    Casestudie 1: Manly Observer

    Manly Observer er en Hyperlocal News-nettsted som serverer publikum i en populær forstad i stranden Sydney, Australia. Nedenfor er hvordan en typisk nyhetsartikkel på nettstedet ser ut:

    Manly observatør

    Vi ser følgende elementer av design klart og til stede ved første øyekast:

    1. Tittel
    2. Forfatternavn og bilde
    3. Dato publisert
    4. Utvalgt bilde relevant for tittelen
    5. Artikkellegeme

    Når vi ser på siden på sidens HTML -kode, kan vi se bruken av semantisk markering.

    Manly Observer Head -seksjonen

    • Titteltaggen inneholder tittelen på nyhetsartikkelen.
    • Sidens Viewport -parametere er lett lesbare.

    Dette er kode som er lett lesbar av et menneske. Det er trygt å anta at en webcrawler vil kunne lese og tolke denne koden med like letthet.

    Nettstedet bruker https: //-ordningen og har ingen popup-annonser eller mellomliggende lasting i den første visningsområdet.

    Manly observatør URL -adresse

    Casestudie 2: Entreprenør

    Entreprenør er et populært magasin for gründere og bedrifter. Slik vises hjemmesiden.

    Gründer

    Nettstedet er lynrask å laste, og det er ingen popup-annonser eller videoer på hjemmesiden selv. Det meste av annonseplassering skjer på individuelle nyhetsartikler.

    Når vi klikker for å "se kilde", ser vi følgende HTML -kode:

    Entreprenør kildekode

    På et øyeblikk kan vi finne ut følgende fra denne koden:

    1. Bruk av semantisk markering: Når vi leser denne koden, er det mulig for oss å forstå hva hver tagg inneholder. For eksempel kan vi se titteltaggen som inneholder tittelen på siden.
    2. Ren Vi hadde diskutert hvordan hodeelementet bare skal inneholde følgende tagger - tittel, stil, meta, lenke, skript, base. I koden over ser vi bare disse elementene og ingenting annet. Dette er en ren

    Når vi blar ned, ser vi følgende kodeelement:

    Gründersjef

    Vi hadde diskutert bruken av Schema.org og OpenGraph (OG) for bilder. For å gjenskape, er Schema.org og OG typer strukturerte data som hjelper webcrawlere med å identifisere spesifikke elementer i koden lettere. Vi ser Schema.org og OG implementert her.

    Lenger nede ser vi også strukturerte datakoder som vist nedenfor:Entreprenørstrukturdata

    Som med vårt forrige eksempel, bruker Entrepreneur.com også https: //-ordningen i sin lenke, har ingen forstyrrende interstitials eller popup-vinduer, og er raskt å laste. Nyhetsartiklene følger et angitt format for tittel, bilde, forfatterattribusjon, dato og hoveddel av innhold. Dette resulterer i en bedre sideopplevelse og forbedret derfor teknisk SEO.

    2.1.9 Handlinger og takeaways

    Etter å ha jobbet gjennom denne leksjonen, bør du kunne gjennomgå og oppdatere eksisterende nyhetssider for å optimalisere design og utforming for å overholde teknisk SEO beste praksis.

    Forrige kapittel
    Tilbake til kapittel
    Neste modul

    Aktiv nå

    1

    Design og layout

    Se mer

    2

    Nettstedets arkitektur

    3

    Sideopplevelse

    4

    Nyheter Sitemap

    5

    Skjema

    6

    Crawlhastighet og -frekvens

    7

    Lenker til sponset og brukergenerert innhold

    8

    Google Publisher Center

    9

    Bing News PubHub

    10

    Annonser, popup-vinduer og beste praksis

    SODP logo

    State of Digital Publishing skaper en ny publikasjon og fellesskap for digitale medier og publiseringsfagfolk, innen nye medier og teknologi.

    • Topp verktøy
    • SEO for utgivere
    • Personvernerklæring
    • Redaksjonell politikk
    • Sitemap
    • Søk etter selskap
    Facebook X-twitter Slakk Linkedin

    STATE OF DIGITAL PUBLISHING – COPYRIGHT 2025