![\"\"](\"https:\/\/inform.click\/wp-content\/uploads\/2022\/11\/post-312376-638384e6e6bd7.webp\")
<\/a><\/p>\n\n Er det en m\u00e5te \u00e5 fikse det p\u00e5?
\n<\/h5>\n
\n WordPress er en veldig Javascript-tung arkitektur. Det er tonnevis av trekkspill, skyveknapper og plugins som drives av jQuery, Vue og andre rammeverk som er klumpete og gjengitt p\u00e5 klientsiden. Den enkleste m\u00e5ten \u00e5 fikse dette p\u00e5 er \u00e5 implementere Javascript p\u00e5 serversiden, som er en kompleks sak og krever utviklere med stor kunnskap om Next.js og andre server-side gjengitte rammer. Dette er selvsagt noe som krever tid, ressurser og spesifikke fagpersoner, noe som ikke mange bedrifter kan forholde seg til.\n<\/p>\n
\n Generelt sett vil den beste tiln\u00e6rmingen for Javascript p\u00e5 WordPress v\u00e6re \u00e5 begrense bruken til grafikkrelaterte oppgaver, for eksempel animering av menyer eller bilder. Den eneste bruken av et skript for en enkel tekstlinje kan \u00f8delegge m\u00e5neder og m\u00e5neder med SEO-arbeid, s\u00e5 husk det n\u00e5r du planlegger WordPress-back- og frontend!\n<\/p>\n
\n Alle de tilpassede feltene!
\n<\/h5>\n
\n Hvis det er en god ting som PHP gj\u00f8r i en WordPress-arkitektur, vil det definitivt v\u00e6re bruken av tilpassede felt. Egendefinerte felt er avgj\u00f8rende for teknisk SEO, spesielt n\u00e5r du planlegger bruken av GTM (Google Tag Manager) og strukturerte data. Spesielt den andre har blitt en ganske grunnleggende del av SEO-verdenen, med dusinvis av egenskaper, attributter og rike resultater som kan oppn\u00e5s ved \u00e5 bruke Schema.orgs<\/strong> markeringer (mer om dette senere). Det er viktig \u00e5 huske p\u00e5 at tilpassede felt krever en form for PHP-kunnskap, s\u00e5 det ville v\u00e6re relativt nyttig \u00e5 l\u00e6re den generelle syntaksen.\n<\/p>\n \n Strukturerte data er OBLIGATORISK i 2019 for enhver teknisk SEO-strategi. Google setter stor pris p\u00e5 nettsteder som er merket med strukturerte data, og derfor er det noe enhver SEO-profesjonell b\u00f8r se n\u00e6rmere p\u00e5. Strukturerte data refererer til bruken av JSON-ld (hovedsakelig) kodede skript som faktisk er en «bekreftelse» p\u00e5 hva innholdet dekker p\u00e5 siden din. P\u00e5 toppen av dette investerer Google i h\u00f8y grad i SERP-rike resultater (stjernevurdering for produktsider, FAQ-bokser og mer) bare for \u00e5 forbedre brukeropplevelsen.\n<\/p>\n \n Schema er et \u00e5pen kildekode-program og det oppdateres daglig, s\u00e5 hvis du ikke har opprettet egendefinerte felt for det, b\u00f8r du gj\u00f8re det n\u00e5. Hypotetisk sett kan du bruke plugins, som Schema-appen, for \u00e5 gj\u00f8re det, men med Schema-markeringer er det alltid best \u00e5 manuelt kode dem ved \u00e5 bruke egenskapene og attributtene som passer best til innholdet ditt.\n<\/p>\n \n Som nevnt ovenfor er WordPress det som kalles en «legacy arkitektur». Med det har vi til hensikt at bibliotekene, rammeverket og motoren som flytter den anses som «foreldet» og «gammel» i dagens front- og backend-verden. Med dette i tankene er det ganske enkelt \u00e5 forst\u00e5 hvorfor visse WordPress-nettsteder ikke gir gode resultater, hastighetsmessig. Hastighet er en veldig viktig rangeringsfaktor for Googles rangeringer, og det er mange forskjellige m\u00e5ter \u00e5 forbedre den p\u00e5 for en teknisk SEO-strategi.\n<\/p>\n \n F\u00f8rst og fremst b\u00f8r du redusere bruken av grafikk-plugins som WPBakery<\/strong>: manuell koding av CSS-en din kan spare deg (ikke engang sp\u00f8ke) for minst 1 sekunds lastetid p\/side. Ideelt sett ville en utvikler v\u00e6re p\u00e5lagt \u00e5 bygge et nettsted med god ytelse, men optimalisering av hastighet, spesielt n\u00e5r det gj\u00f8res ved \u00e5 komprimere bilder og andre mindre ressurser, kan gj\u00f8res av hvem som helst.\n<\/p>\n \n Vi har dekket hvordan Google gjennoms\u00f8ker Javascript, og n\u00e5 er vi klare til \u00e5 skissere hvordan du forbereder WordPress-nettstedet ditt for et optimalt gjennomgangsbudsjett. For «Gjennoms\u00f8kingsbudsjett» har vi tenkt tidsrammene som Google skanner et nettsted for deretter \u00e5 indeksere og rangere dem p\u00e5 SERP. Det er nok en gang mange strategier som kan brukes for \u00e5 optimalisere WordPress-nettstedets gjennomgangsbudsjett, men de starter alle med \u00e5 analysere loggfilene.\n<\/p>\n \n Ved \u00e5 bruke verkt\u00f8y som ScreamingFrog<\/strong> eller Deepcrawl<\/strong>, vil du kunne analysere og skissere hvilke sider som gjennoms\u00f8kes mest, og generelt vil du se hvordan Google faktisk gjennoms\u00f8ker eiendeler som temafiler mer enn faktiske landingssider. Dette er selvf\u00f8lgelig et enormt problem, siden du effektivt kaster bort Googlebots tid ved \u00e5 la ham gjennoms\u00f8ke deler av nettstedet ditt som ikke er s\u00f8keordorientert, og derfor begrenser rangeringspotensialet ditt. N\u00e5r dette er bekreftet ved \u00e5 gj\u00f8re en skikkelig loggfilanalyse, kan du fjerne de ressursene som blir gjennoms\u00f8kt fra Googlebots gjennoms\u00f8kingsbudsjett ved \u00e5 ikke tillate dem i robots.txt-filen. Du finner mer informasjon om hvordan du gj\u00f8r det her<\/a>.\n<\/p>\n \n Som du kanskje vet, setter Google stor pris p\u00e5 hvert nettsteds mobilversjon, til det punktet som mobilindeksen har blitt talt f\u00f8rst for siden 2018 (2017 teknisk sett, men den ble fullt registrert i 2018) for rangeringsform\u00e5l. Det er ekstremt viktig \u00e5 forst\u00e5 at alle disse strategiene ogs\u00e5 gjelder for mobil n\u00e5r du planlegger WordPress-arkitekturen din med litt st\u00f8rre vekt p\u00e5 gjennomgangsbudsjettet, bare fordi Google gjennoms\u00f8ker mobilversjoner av nettsteder langt raskere.\n<\/p>\n \n P\u00e5 WordPress har noen apputviklere laget en AMP-plugin som du vil kunne lage, forbedre og optimalisere, til slutt, WordPress-nettstedets mobilhastighet. AMP (Accelerated Mobile Pages) er noe som ogs\u00e5 kan hjelpe fremhevede resultater p\u00e5 Google hvis innholdet\/produktet ditt ikke er s\u00e6rlig orientert mot lange former for innhold.\n<\/p>\n \n WordPress er en enkel arkitektur \u00e5 sette opp, men ekstremt kompleks \u00e5 optimalisere, spesielt n\u00e5r det kommer til teknisk SEO. V\u00e6r oppmerksom p\u00e5 at disse strategiene bare er et skjelett av hva teknisk SEO brukt p\u00e5 WordPress faktisk er, ettersom det er tonnevis av variabler inkludert i ligningen, alt fra \u00e5 sette opp detaljerte GTM-regler til \u00e5 optimalisere \u00f8ktkvaliteten avhengig av nettstedets m\u00e5l. N\u00e5r dette er sagt, er det mulig \u00e5 lage og levere en teknisk SEO-strategi av ekstremt h\u00f8y kvalitet via WordPress, spesielt hvis du optimaliserer backend fra starten. WordPress kan v\u00e6re en gammel arkitektur, men det er mange m\u00e5ter \u00e5 «overg\u00e5» dette f\u00f8rste problemet, som nevnt ovenfor.\n<\/p>\n<\/p>\n\n Apropos skjema…
\n<\/h5>\n\n Hastighet: WordPress st\u00f8rste problem
\n<\/h5>\n<\/a><\/p>\n\n Slik planlegger du backend-en din for crawling-optimalisering
\n<\/h5>\n\n Hva med mobil?
\n<\/h5>\n\n \u00c5 konkludere
\n<\/h4>\n