Søgemaskineoptimering på .NET
I princippet burde der ikke være forskel på resultaterne af søgemaskineoptimering, alt efter hvilket backend system, OS, software osv man anvender. Men det er der! Notes domino er noget af det værste der findes. Men tæt efterfulgt kommer webapplikationer bygget på [tag]Microsoft .NET[/tag]. I modsætning til Domino er MS .NET dog ikke fuldkommen umuligt – man kan faktisk godt søgemaskineoptimere det, men det er svært. Meget svært! Det tager tid og det er dyrt.
Jeg sidder lige nu med et stort internationalt projekt, der som så mange andre store projekter i dag bygger på Microsoft .NET platformen. Og det er som sådan også en rigtig god platform. Udviklerne er glade for den og når systemerne er lavet færdigt er det ufatteligt stabilt og skalerbart. Desværre er det rent ud sagt oftest noget lort i forhold til søgemaskineoptimering.
Der er en hel række problemer i forhold til søgemaskineoptimering på Microsoft .NET, som skyldes de krav .NEt stiller. Mange andre af de problemer man stødder ind i på .NET applikationer kan ikke direkte tilskrives uhensigtsmæssigheder i .NET men skyldes den måde mange udvikler opbygger deres applikationer i .NET. Som f.eks. det her projekt jeg sidder med …
Projektet involverer nogle blogs og forums, som skal integreres i websitet. Normalt ville jeg have valgt en PHP baseret løsning til forums og blogs da der findes langt flere søgemaskinevenlige løsninger i PHP, men da resten af websitet kører .NET var det et krav at community-delen også gjorde det.
En af de problemer jeg er løbet ind i med det valgte .NET system er de mange forskellige URL’s systemet genererer til de samme sider. Således fandt vi ikke mindre end 7 forskellige URLs til hver eneste debattråd i forum’et! Der er to store problemer i dette:
- Hvis søgemaskinerne finder mere end en URL til det samme indhold vil de enten droppe den ene, den anden eller alle sammen. Og tro mig, de vælger aldrig at beholde den version (om nogen) som du ønsker.
- Når der findes flere URLs til samme sider vil de naturlige links, som brugerne af debatten laver, sprede sig over alle 7 URL-versioner. De fleste links, og den mefølgende forbedrede linkpopularitet, vil derfor blive spildt. Så selvom du skulle være så heldig at søgemaskinerne ikke dropper dine sider helt, vil de sansynligvis ikke ranke på en skid.
Begge dele gør, at en debat med en sådan struktur vil få reduceret den potentielle gennemslagskraft i søgemaskinerne med alt fra 70-100% Ikke godt! Det SKAL simpelthen fikses.
Dette problem kan man dig ikke direkte tilskrive .NET som sådan – det er i højere grad et udtryk for en helt forkert opbygning af systemet. Det er kort sagt udviklernes skyld.
Et andet udbredt problem på .NET løsninger kan derimod tilskrives .NET direkte – og det er den såkaldte view_state, der bl.a. bruges til at holde styr på brugersessions. I modsætning til cookies, udskrives view_state koder direkte i HTML-koden og nogle gange kan disse view_state koder være særdeles lange. Det er ikke længe siden jeg sad med en kunde, hvor den første del af koden på alle sider indeholdt en view_state kode på over 18.000 tegn! De er over 25 A4 sider når man printer det ud! Det holder simpelt hen ikke. Mange søgemaskiner vil slet ikke komme forbi al den kode og ned til selve sidens indhold. Det er katastrofalt.
Heldigvis kan der næsten altid gøres noget ved dette, og de mange andre problemer der er med .NET i forhold til søgemaskineoptimerig. Du skal blot være opmærksom på at det dels kan være virkelig svært at finde alle problemerne på en .NET løsning og dels kan det godt tage rigtig mange timer at fikse det hele. I den konkrete sag jeg sidder med drejer det som om flere ugers ekstra programmering og rådgivning. Alt i alt problemløsning i 100-tusind kroners klassen.
Lars Buur skriver
Interessant! – ville de to primære problemer du beskriver ikke kunne løses rimeligt simpelt ved at dels indføre en url rewriter (en rigtig god en findes her -> http://workspaces.gotdotnet.com/rewriter) – samt ved at slå viewstate fra på de forskellige kontroller som benyttes?
Mikkel deMib Svendsen skriver
Du har til dels ret med hensyn til view_state, som rigtig nok kan slås fra der hvor det alligevel ikke bruges. Ofte viser det sig bare ikke at være helt så enkelt, fordi det faktsik bliver brugt en masse steder hvor man ikke lige ville forvente det.
Med hensyn til URL-rewrite plejer vi at bruge ISAPI-rewrite der understøtter langt de fleste funtioner fra den originale Apache mod_rewrite, men det ændrer ikke på probemet med de mange forskellige URL’s til det samme indhold. URL-omskrivning/remapping fjerner nemlig ikke adgangen til de gamle URL’er – det laver bare nogle nye.
Lars Buur skriver
Den url rewriter jeg henviste til benytter et xml dokument med alle de “mappings” som skal rewrites – disse kan håndtere regulære udtryk – og dette giver mulighed for at man kan få mange forskellige url´er til blive en og samme.
f.eks.
Jeg ved selvfølgelig ikke om dette kan løse problemet – men det kunne jo være 🙂
Mikkel deMib Svendsen skriver
Jeg kender ikke lige den konkrete løsning, men hvis ikke den samtidig blokerer eller redirecter alle andre mullige addresser til de samme sider, hvilket URL-omskrivning i sig selv ikke gør, så er det kun den halve løsning.
Det er ikke nok at man ikke kan navigere sig frem til de forskellige URL-formater. Det svarer til dem der ligger et regneark med alle deres password på deres server og så undrer sig over når folk finder den … jamen eg gav ikke addressen til nogle … Det er simpelt hen for usikert. For hvis søgemaskinerne af en eller anden grund (andre der lnker, toolbar besøg etc) finder adressen på en URL i et andet format der virker, kan man risikere at de kan crawle hele websitet i det format – og så har du pludselig to 100% identiske kopier … så længe det varer …
Kevin Steffer skriver
Jeg har med glæde læst nyhedsbreve – dejligt du ikke har glemt os!
Men jeg snublede lige over de 18.000 tegns viewstate og lavede lige 10 minuters research som tak for nyhedsbrevet og min tanke var at flytte viewstate til bunden af filen, så kommer det relevante indhold da først, og det er der også lavet en løsning på.
Se:
http://www.structured-solutions.net/MovingVIEWSTATEToTheBottomOfThePageRedux.aspx
Efter 2 min havde jeg implementeret modulet i et ASP.NET 2.0 Website projekt.
Og mit HTML output ser nu således ud efter at have 1 TextBox på siden:
Untitled Page
Mikkel deMib Svendsen skriver
Ja, det vil helt klart være en forbedring at flytte view state til bunden, frem for topen som det oftest findes i. Men jeg vil nu alligevel fraråde at fodre søgemaskinernes spiders med 18.000-tegns view state crap 🙂 Keep it simple …!
Claus Pedersen skriver
Nu synes jeg det er lige voldsomt nok at skrive at web applikationer skrevet i .Net er noget af det værste der findes i forhold til søgemaskiner.
Jeg er sikker på at de problemer du oplever med mange links til samme post kan findes i et hvilket som helst sprog hvis de samme udviklere sad bag.
.Net har i øvrigt indbygget mulighed for httphandlers der gør det muligt forholdsvist simpelt for udvikleren at skrive sin egen rewriter f.eks. udfra sin database.
Mikkel deMib Svendsen skriver
Claus, netop i forhold til mange-til-en problematikken skriver jeg jo “Dette problem kan man dog ikke direkte tilskrive .NET som sådan …”.
Faktum er dog stadig at det ALTID koster langt mere at optimere et .NET site end de fleste andre arkitekturer. Nogle gange skyldes det selve .NET arkitekturen, og nogle gange skyldes det udviklere der har låst sig selv fast i en masse dårlige vaner. Men uanset årsagen er resultatet altid det samme: Det er dyrrere at optimere et .NET website
Mange af problemerne kunne som sagt godt løses, hvis dem der udvikler .NET applikationer gad at sætte sig ind i de relevante bruger- og søgemaskinemæssige krav der er. Jeg har optimeret masser af .NET løsninger så de er så godt som optimale men hver eneste gang har det kostet kunden en helvedes masse penge – penge der kunne have været sparet hvis de .NET systemer de havde valgt var konstrueret bedre fra bunden af.