SEO-vänliga HTML-genererande ramverk?

Permalänk

SEO-vänliga HTML-genererande ramverk?

Tjo! Jag undrar vilka SEO-vänliga webbutvecklings-frameworks som vanligen används om du vill skapa en enorm webbplats med färdigrenderade HTML-filer (en länk tar dig således till en ny HTML-fil) som kan läsas av diverse "robotwebbspindlar"? Är det "Astro", "Next.js" eller något annat som gäller då?

Tanken är att i takt med att en HTML-baserad webbplats växer så kommer du behöva inkludera nya länkar i exempelvis nav-elementet. Då vill du ju inte behöva gå in i varje enskild HTML-fil för att uppdatera nav-elementet där. PHP som jag förstår det renderar ju HTML-kod på serversidan och sedan skickar som HTTP-svar men således finns det inga HTML-filer på serversidan för "web crawlers" att nosa i? Men samtidigt förstår jag inte då hur WordPress-bloggartiklar (PHP-baserat) kan lyckas "web crawlas" och därmed hamna på sökresultatsidor?

När jag googlat/frågat chatgpt3.5 på/om saken så verkar just "Astro" eller "Next.js" vara att föredra. Därför tänkte jag fråga här vad andra känner till är "industri-/branschstandard" för SEO-vänliga HTML-baserade webbplatser? Med HTML-baserad menar jag att det inte är en SPA (=endast en HTML-fil).

Tack för svar på förhand!

Mvh,
WKL.

Visa signatur

<WKL:"En kodrad i taget!";/>

Permalänk
Medlem
Skrivet av WebbkodsLärlingen:

Tanken är att i takt med att en HTML-baserad webbplats växer så kommer du behöva inkludera nya länkar i exempelvis nav-elementet. Då vill du ju inte behöva gå in i varje enskild HTML-fil för att uppdatera nav-elementet där. PHP som jag förstår det renderar ju HTML-kod på serversidan och sedan skickar som HTTP-svar men således finns det inga HTML-filer på serversidan för "web crawlers" att nosa i? Men samtidigt förstår jag inte då hur WordPress-bloggartiklar (PHP-baserat) kan lyckas "web crawlas" och därmed hamna på sökresultatsidor?

Här har du en tankevurpa. En crawler kan inte gå inte igenom filer på din server (det hade ju varit ett enormt säkerhetshål!). Som vilken annan HTTP-klient som helst får den nöja sig med HTTP-svaren och där kan den ju omöjligt veta om svaret är statiskt eller dynamiskt genererat (med till exempel PHP). Det ser likadant ut för klienten om du dynamiskt inkluderar samma nav.html i flera sidor med PHP eller kopierar innehållet i nav.html till alla dina undersidor och serverar allt statiskt.

Visa signatur

Spela Swemantle! Du vet att du vill.

Ibland har jag fel, men då är det någon annans fel.

Permalänk
Medlem

Fallstudie...

Kollegorna byggde typ 42 sajter åt ett större företag. Varje sajt hade 1-3 språk (men typ ett dussin språk totalt) och allt genererades som statiska HTML-sidor. Sajterna blev skitsnabba att ladda eftersom de kunde cachas helt och hållet på CDN, vilket ger bonus på SEO-fronten. Ramverket som genererar sidorna är Gatsby.

Backenden är irrelevant, men vi kan låtsas att det är en vanlig högnormaliserad relationsdatabas, där varje liten del av alla sidtyper är sitt eget lilla dataobjekt, dock ligger alla språk direkt på objektet. Samma databas används för alla sajter, eftersom man vill ha möjligheten att återanvända all information på alla sajter och på alla sidtyper. Att lägga till ett visst objekttyp på en viss sidtyp ska naturligtvis gå att göra helt dynamiskt.

Allt är frid och fröjd till kunden kommer på att de vill kunna publicera saker snabbt. Det är ju rimligt. Jahapp, man har ändrat ett objekt någonstans nere i datahierarkin, men på vilka sidtyper används objektet? Och på vilka av de 42 sajterna används just det objektet på en sida av dessa sidtyper?

Det är inte läge att generera om rubbet varje gång, det kostar icke-triviala pengar i processortid, eftersom man lagt alltihop i molnet. Ramverket har inget riktigt stöd för att bara generera om rätt saker, det begriper sig inte riktigt på just den här backenden så bra (det är ett generellt verktyg) att den kan göra så smarta saker. Att skriva "databasfrågor" för varje objekttyp är varken kul eller speciellt underhållsvänligt -- det krävs ju en specifik fråga per sidtyp-objekttyp-kombination, vilka såklart är dynamiska på tre ledder (sidtyper kan tillkomma, objekttyper kan tillkomman och användningen av objekttyperna förändras). Hierarkin är naturligtvis inte lika djup överallt. Eftersom alla språk ligger på objektet så kan man inte härleda ändringen till språknivån, så man får generera om sidor på sajter som har objektet men inte det ändrade språket.

Sedan kommer kunden på att de vill kunna köra preview på de objekt de har ändrat, innnan de publicerar dem. Rimligt, kan man tycka, speciellt som det tar en halv evighet att publicera om något. Samma fråga igen, vilken sida, vilket språk, vilken sajt är det man vill titta på? Och det råkar vara så att man har valt att lägga grejerna i ett generellt moln i stället för ramverksleverantörens SaaS, där det finns bra stöd för detta.

Nå, vi är ju konsulter, det vi är bra på är att ta betalt för fulhackade lösningar. Lös problemet.

Lärdomen är att generering av statiska sidor kan vara riktigt bra. Om man kommer överens med kunden om att man ska köra genereringen batchvis ganska sällan - och om man har en lösning på preview-problematiken.

Permalänk
Medlem
Skrivet av KAD:

Fallstudie...

Kollegorna byggde typ 42 sajter åt ett större företag. Varje sajt hade 1-3 språk (men typ ett dussin språk totalt) och allt genererades som statiska HTML-sidor. Sajterna blev skitsnabba att ladda eftersom de kunde cachas helt och hållet på CDN, vilket ger bonus på SEO-fronten. Ramverket som genererar sidorna är Gatsby.

Backenden är irrelevant, men vi kan låtsas att det är en vanlig högnormaliserad relationsdatabas, där varje liten del av alla sidtyper är sitt eget lilla dataobjekt, dock ligger alla språk direkt på objektet. Samma databas används för alla sajter, eftersom man vill ha möjligheten att återanvända all information på alla sajter och på alla sidtyper. Att lägga till ett visst objekttyp på en viss sidtyp ska naturligtvis gå att göra helt dynamiskt.

Allt är frid och fröjd till kunden kommer på att de vill kunna publicera saker snabbt. Det är ju rimligt. Jahapp, man har ändrat ett objekt någonstans nere i datahierarkin, men på vilka sidtyper används objektet? Och på vilka av de 42 sajterna används just det objektet på en sida av dessa sidtyper?

Det är inte läge att generera om rubbet varje gång, det kostar icke-triviala pengar i processortid, eftersom man lagt alltihop i molnet. Ramverket har inget riktigt stöd för att bara generera om rätt saker, det begriper sig inte riktigt på just den här backenden så bra (det är ett generellt verktyg) att den kan göra så smarta saker. Att skriva "databasfrågor" för varje objekttyp är varken kul eller speciellt underhållsvänligt -- det krävs ju en specifik fråga per sidtyp-objekttyp-kombination, vilka såklart är dynamiska på tre ledder (sidtyper kan tillkomma, objekttyper kan tillkomman och användningen av objekttyperna förändras). Hierarkin är naturligtvis inte lika djup överallt. Eftersom alla språk ligger på objektet så kan man inte härleda ändringen till språknivån, så man får generera om sidor på sajter som har objektet men inte det ändrade språket.

Sedan kommer kunden på att de vill kunna köra preview på de objekt de har ändrat, innnan de publicerar dem. Rimligt, kan man tycka, speciellt som det tar en halv evighet att publicera om något. Samma fråga igen, vilken sida, vilket språk, vilken sajt är det man vill titta på? Och det råkar vara så att man har valt att lägga grejerna i ett generellt moln i stället för ramverksleverantörens SaaS, där det finns bra stöd för detta.

Nå, vi är ju konsulter, det vi är bra på är att ta betalt för fulhackade lösningar. Lös problemet.

Lärdomen är att generering av statiska sidor kan vara riktigt bra. Om man kommer överens med kunden om att man ska köra genereringen batchvis ganska sällan - och om man har en lösning på preview-problematiken.

Det låter ju som riktiga klåpare som inte inser att man behöver ett CMS för ett sådant upplägg. Tjänstefel. Jag hade inte betalat en krona som beställare.