Skandalomsusade Jajja har undersökt vilka publiceringsverktyg som syns bäst i Google. Jimmy Wirsborg säger att Jajja gått igenom 4000 webbplatser. Hur undersökningsunderlaget för ett system, och inte en webbplats, tagits fram är okänt. Graden av SEO främst skapas som känt främst av implementationspartner samt sedan löpande av redaktörerna själva.
Därför borde ett resultat i en undersökning som denna kunna påverkas från timme till timme.
Positivt är däremot att Jajja fokuserar på CMS-systemet och inte på överflödig och ”ovanpålagd” SEO-konsulting.
Litium Studio vann följt av tillgänglighetsfokuserade Fakta Sitepilot och Xeleras Drupal. Polopoly kom fyra och Roxen fick en mittenplacering. Ökända bolaget Yreg’s okända CMS kom sist.
EPiServer finns enligt SEO-företaget inte med då ”det finns så många varianter av systemet”. Ingen partner sägs ”implementerat verktyget med dess moduler på ”rätt” sätt”. Undrar om Netrelations håller med?
Kommentarer
Så klart vi inte gör ;)
/Anton
Så klart vi inte gör ;)
/Anton
Jajja är välkomna att få ta del av hur en tekniskt sökmotoroptimerad EPiServer ser ut när som helst.
Konstigt att man kan dra över 6000 EPiServer-sajter implementerade av partners över hela världen över en kam på ett sånt generellt sätt. I min värld gör det att trovärdigheten på undersökningen sjunker…dramatiskt!
Jajja är välkomna att få ta del av hur en tekniskt sökmotoroptimerad EPiServer ser ut när som helst.
Konstigt att man kan dra över 6000 EPiServer-sajter implementerade av partners över hela världen över en kam på ett sånt generellt sätt. I min värld gör det att trovärdigheten på undersökningen sjunker…dramatiskt!
För övrigt har ni ju ascoola IP:n på det nät ni använder på Netrelations. Jan kom från janne.netrelations.se 213.115.122.35 och Anton från anton.netrelations.se 213.115.122.32. Hoppas inte det var någon företagshemlighet? Eller att ni har någon kontrollgalen chef!
För övrigt har ni ju ascoola IP:n på det nät ni använder på Netrelations. Jan kom från janne.netrelations.se 213.115.122.35 och Anton från anton.netrelations.se 213.115.122.32. Hoppas inte det var någon företagshemlighet? Eller att ni har någon kontrollgalen chef!
Att det finns många varianter av EPiServer är inte en korrekt bedömning. Det finns flera versioner men vilka system, som har den farten, har inte det? Att det sedan finns flera tillval är en annan sak. Det bygger hela Drupal på om jag inte missminner mig.
I grunden är EPiServer samma kärna sedan en lång tid tillbaka, visserligen ombyggd några varv.
Ett problem vid bedömningen av EPiServers sajter är dock att det ligger stort ansvar hos implementatören eftersom verktyget kan användas på många olika sätt för att nå samma mål. Något som jag som leverantör upplever det dåligt ställt med många andra verktyg.
Att det finns många varianter av EPiServer är inte en korrekt bedömning. Det finns flera versioner men vilka system, som har den farten, har inte det? Att det sedan finns flera tillval är en annan sak. Det bygger hela Drupal på om jag inte missminner mig.
I grunden är EPiServer samma kärna sedan en lång tid tillbaka, visserligen ombyggd några varv.
Ett problem vid bedömningen av EPiServers sajter är dock att det ligger stort ansvar hos implementatören eftersom verktyget kan användas på många olika sätt för att nå samma mål. Något som jag som leverantör upplever det dåligt ställt med många andra verktyg.
Givetvis är det helt galet. Det första man måste ta reda på är om det överhuvudtaget går att anpassa HTML:en som produceras. Om det inte går (eller är jobbigt och tidsödande, se Sharepoint) så ligger ansvarat på CMS:et. Annars är det, som Martin också säger, helt upp till leverantören och redaktörerna vad som produceras.
Jajja gör bort sig igen.
Givetvis är det helt galet. Det första man måste ta reda på är om det överhuvudtaget går att anpassa HTML:en som produceras. Om det inte går (eller är jobbigt och tidsödande, se Sharepoint) så ligger ansvarat på CMS:et. Annars är det, som Martin också säger, helt upp till leverantören och redaktörerna vad som produceras.
Jajja gör bort sig igen.
Hej såg ditt inlägg i debatten och tänkte bara infoga en rättelse. Inför denna utvärdering så har det inte genomgåtts 4000 webbplatser utan i vår pressrelease, som jag antar att du försökt citera mig ifrån, så framgår det att vi ”genom åren genomfört över 4 000 kundprojekt och det är inte ovanligt att kundernas publiceringsverktyg försvårat sökoptimeringen.”. Det är alltså erfarenheten av de kundprojekten som lett fram till att sökmotorvänligheten i CMS måste bli en mer prioriterad fråga.
Sedan har frågorna som ställts varit ifall det som levereras av de olika tillverkarna uppfyller kraven. D.v.s. innan kunden kommer in i bilden och gör ändringar och eventuellt minskar/ökar nivån av sökmotorvänlighet. Alltså kommer inte resultatet att ändras från en timme till en annan om inte leverantören släpper en ny version. Ifall du har förslag på förbättringar får du gärna maila mig dem direkt, [email protected], så får jag se ifall det är något vi kanske kan implementera i nästa utvärdering.
Problemen gällande EPiServer är att vi får skribentinlogg med minimala rättigheter från kunder då det är det inlogg de själva använder. När man sedan ber om antingen funktionalitet eller tillgång till koden så stöter vi på motstånd från leverantörerna istället för öppenhet att lösa kundens problem. Det är i varje fall vår erfarenhet av EPiServer och de leverantörer som vi kommit i kontakt med. Det finns undantag där man är tillmötesgående och direkt öppnar upp eller lägger till funktionalitet. Men en betygssättning av EPiServer är alltså väldigt beroende på leverantör och därför har vi också valt att inte ha med i denna utvärdering. Att EPiServer som system är kraftfullt och kapabelt till extremt mycket är det nog ingen som tvivlar på.
Om Netrelations har någon lösning på en optimering via ett skribentinlogg vet jag dock inte men jag kommer att skicka ett mail efter denna kommentar till dem och fråga. För det är väldigt intressant för oss.
Sedan verkar din bild länka fel, den länkar någon gammal tråd från webmaster network, PDF:en du troligen velat länka ligger på http://www.jajja.com/_pdfs/jajja-cms-test.pdf.
Vill också passa på och tacka för en bra blogg, jag har varit här och läst inlägg tidigare vet jag. Tyvärr har jag inte haft tid att följa din blogg.
Hej såg ditt inlägg i debatten och tänkte bara infoga en rättelse. Inför denna utvärdering så har det inte genomgåtts 4000 webbplatser utan i vår pressrelease, som jag antar att du försökt citera mig ifrån, så framgår det att vi ”genom åren genomfört över 4 000 kundprojekt och det är inte ovanligt att kundernas publiceringsverktyg försvårat sökoptimeringen.”. Det är alltså erfarenheten av de kundprojekten som lett fram till att sökmotorvänligheten i CMS måste bli en mer prioriterad fråga.
Sedan har frågorna som ställts varit ifall det som levereras av de olika tillverkarna uppfyller kraven. D.v.s. innan kunden kommer in i bilden och gör ändringar och eventuellt minskar/ökar nivån av sökmotorvänlighet. Alltså kommer inte resultatet att ändras från en timme till en annan om inte leverantören släpper en ny version. Ifall du har förslag på förbättringar får du gärna maila mig dem direkt, [email protected], så får jag se ifall det är något vi kanske kan implementera i nästa utvärdering.
Problemen gällande EPiServer är att vi får skribentinlogg med minimala rättigheter från kunder då det är det inlogg de själva använder. När man sedan ber om antingen funktionalitet eller tillgång till koden så stöter vi på motstånd från leverantörerna istället för öppenhet att lösa kundens problem. Det är i varje fall vår erfarenhet av EPiServer och de leverantörer som vi kommit i kontakt med. Det finns undantag där man är tillmötesgående och direkt öppnar upp eller lägger till funktionalitet. Men en betygssättning av EPiServer är alltså väldigt beroende på leverantör och därför har vi också valt att inte ha med i denna utvärdering. Att EPiServer som system är kraftfullt och kapabelt till extremt mycket är det nog ingen som tvivlar på.
Om Netrelations har någon lösning på en optimering via ett skribentinlogg vet jag dock inte men jag kommer att skicka ett mail efter denna kommentar till dem och fråga. För det är väldigt intressant för oss.
Sedan verkar din bild länka fel, den länkar någon gammal tråd från webmaster network, PDF:en du troligen velat länka ligger på http://www.jajja.com/_pdfs/jajja-cms-test.pdf.
Vill också passa på och tacka för en bra blogg, jag har varit här och läst inlägg tidigare vet jag. Tyvärr har jag inte haft tid att följa din blogg.
EPiServer har en ganska skarp uppdelning mellan innehåll och mallproducerandet. Mallarna och koden görs i Visual Studio och där vill man oftast inte ha in externa partners för modifiering av SEO-aspekter. Kan det var en anledning till motviljan du upplever, Jimmy?
EPiServer har en ganska skarp uppdelning mellan innehåll och mallproducerandet. Mallarna och koden görs i Visual Studio och där vill man oftast inte ha in externa partners för modifiering av SEO-aspekter. Kan det var en anledning till motviljan du upplever, Jimmy?
Hej Jimmy. Vad är de 16 kriterier ni kan, och har kunnat, göra i Polopoly och Drupal installationer men som ni inte kunnat göra i EPiServer? Vad är det Jajja så gärna vill göra i ”koden”? Är det hos er EPiServer-användande kund (Fujifilm intranät) Fujicolor ni inte fått tillräcklig access för SEO hos? Hittar inga andra EPiServerkunder på http://kundcase.jajja.com/.
Det är inte min sak att avgöra, men med tanke på reaktionerna efter ”Litium och SiteDirect syns bäst i Google” tror jag ni kommer få väldigt svårt att nå bättre framgång med ett eventuellt test 2009.
Det handlar inte så mycket om just testet som den generella inställningen till SEO. Den borde ora de svenska SEO-aktörerna.
Bilden länkar rätt.
Hej Jimmy. Vad är de 16 kriterier ni kan, och har kunnat, göra i Polopoly och Drupal installationer men som ni inte kunnat göra i EPiServer? Vad är det Jajja så gärna vill göra i ”koden”? Är det hos er EPiServer-användande kund (Fujifilm intranät) Fujicolor ni inte fått tillräcklig access för SEO hos? Hittar inga andra EPiServerkunder på http://kundcase.jajja.com/.
Det är inte min sak att avgöra, men med tanke på reaktionerna efter ”Litium och SiteDirect syns bäst i Google” tror jag ni kommer få väldigt svårt att nå bättre framgång med ett eventuellt test 2009.
Det handlar inte så mycket om just testet som den generella inställningen till SEO. Den borde ora de svenska SEO-aktörerna.
Bilden länkar rätt.
Pingback: Jajja mäter sökmotorvänlighet hos publiceringssystem
Roligt att en intensiv diskussion om EPiServer kommer upp. Rätt använd är den kanon, det kan jag hålla med Martin och killarna på Netrelations.
Men i händerna på mindre kompetenta (eller mindre EPiServer utbildade) webredaktörer så är det en katastrof. Har sett måååånga sidor som har extrema problem med SEO i EPiServer. Det kunde dem säkert haft på andra plattformar också, men det tycks vara väldigt vanligt på just detta CMS..
Roligt att en intensiv diskussion om EPiServer kommer upp. Rätt använd är den kanon, det kan jag hålla med Martin och killarna på Netrelations.
Men i händerna på mindre kompetenta (eller mindre EPiServer utbildade) webredaktörer så är det en katastrof. Har sett måååånga sidor som har extrema problem med SEO i EPiServer. Det kunde dem säkert haft på andra plattformar också, men det tycks vara väldigt vanligt på just detta CMS..
Tillägg, missa inte min och Nikkes fortsatta diskussion om huruvida en sådan här ”undersökning” egentligen behövs eller om det alltid kommer sluta i ett sedvanligt ”upphandlingsunderlag”: http://www.lindqvist.com/b/jajja-mater-sokmotorvanlighet-hos-publiceringssystem#comment-100893
Tillägg, missa inte min och Nikkes fortsatta diskussion om huruvida en sådan här ”undersökning” egentligen behövs eller om det alltid kommer sluta i ett sedvanligt ”upphandlingsunderlag”: http://www.lindqvist.com/b/jajja-mater-sokmotorvanlighet-hos-publiceringssystem#comment-100893
…Om Netrelations har någon lösning på en optimering via ett skribentinlogg …
Det handlar om att en konsult som implementerar en EPiServerlösning måste veta vad de gör, eftersom det första kriteriet för att överhuvudtaget kunna hamna högt upp i sökresultatet är att EPiServer sökoptimeras rent tekniskt. Det gör vi i alla våra leveranser utan att det är en extra ”feature”. Vi tar inte heller extra betalt. Vi vet hur man gör helt enkelt, och på frågan om vi skulle släppa in någon extern SEO-konsult, exempelvis Jajja, i en EPiServer-leverans, så är det självklart ett rungande nej. Vi släpper inte in någon i koden, men om en av våra kunder vill optimera innehållet via redaktörsläget, så är det fritt fram eftersom den tekniska sökmotoroptimeringen redan är på plats. Att det funkar utmärkt bra ser vi i varje leverans!
…Om Netrelations har någon lösning på en optimering via ett skribentinlogg …
Det handlar om att en konsult som implementerar en EPiServerlösning måste veta vad de gör, eftersom det första kriteriet för att överhuvudtaget kunna hamna högt upp i sökresultatet är att EPiServer sökoptimeras rent tekniskt. Det gör vi i alla våra leveranser utan att det är en extra ”feature”. Vi tar inte heller extra betalt. Vi vet hur man gör helt enkelt, och på frågan om vi skulle släppa in någon extern SEO-konsult, exempelvis Jajja, i en EPiServer-leverans, så är det självklart ett rungande nej. Vi släpper inte in någon i koden, men om en av våra kunder vill optimera innehållet via redaktörsläget, så är det fritt fram eftersom den tekniska sökmotoroptimeringen redan är på plats. Att det funkar utmärkt bra ser vi i varje leverans!
Tror att Andreas är sanningen på spåret. Och Jan verifierar det med sin kommentar om ett rungande nej. Och när någon som Netrelations som vet vad man gör implementerar EPiServer så blir det som Markus säger kanon och problemfritt. En rätt uppsatt EPiServer behöver ingen direkt sökmotoroptimering av sin kod, däremot kan det finnas mycket att göra redaktionellt men det är ju en annan historia.
Tyvärr har vi på Jajja precis samma erfarenhet som Markus på området. Det är en majoritet av webbplatserna som vi kommer i kontakt med som har saker som vi skulle vilja åtgärda på kodsidan. Jag har till och med sett implementationer där man inte särskiljer olika webbplatsers eller domäners innehåll. Utan där man låter en domän visa andra domäners innehåll nästan helt utan styrning, vilket blev pankaka när Google indexerade innehåll på fel domän.
Jag skulle nog kunna skriva en mindre bok med olika knasiga implementationer. Frågan är istället hur man utvärderar ett verktyg där vi å ena sidan har Netrelations som implementerar EPiServer så att det skulle få högsta betyg å andra sidan har vi implementationer där eget domän inte är garanterat och där det inte går att skriva titlar, description eller få w3c-validerad kod och alltså i stort sett få en noll i betyg? Sätter man en nolla så motsätter sig nog Netrelations och många andra bra leverantörer av EPiServer detta och sätter man full poäng så hamnar alla säljare och kundansvariga i situationer där de måste förklara för kunder varför de inte syns och varför optimering inte är möjlig och så vidare i deras implementation av EPiServer.
Fujifilm är inte en av de kunderna som vi haft problem med.
Tror att Andreas är sanningen på spåret. Och Jan verifierar det med sin kommentar om ett rungande nej. Och när någon som Netrelations som vet vad man gör implementerar EPiServer så blir det som Markus säger kanon och problemfritt. En rätt uppsatt EPiServer behöver ingen direkt sökmotoroptimering av sin kod, däremot kan det finnas mycket att göra redaktionellt men det är ju en annan historia.
Tyvärr har vi på Jajja precis samma erfarenhet som Markus på området. Det är en majoritet av webbplatserna som vi kommer i kontakt med som har saker som vi skulle vilja åtgärda på kodsidan. Jag har till och med sett implementationer där man inte särskiljer olika webbplatsers eller domäners innehåll. Utan där man låter en domän visa andra domäners innehåll nästan helt utan styrning, vilket blev pankaka när Google indexerade innehåll på fel domän.
Jag skulle nog kunna skriva en mindre bok med olika knasiga implementationer. Frågan är istället hur man utvärderar ett verktyg där vi å ena sidan har Netrelations som implementerar EPiServer så att det skulle få högsta betyg å andra sidan har vi implementationer där eget domän inte är garanterat och där det inte går att skriva titlar, description eller få w3c-validerad kod och alltså i stort sett få en noll i betyg? Sätter man en nolla så motsätter sig nog Netrelations och många andra bra leverantörer av EPiServer detta och sätter man full poäng så hamnar alla säljare och kundansvariga i situationer där de måste förklara för kunder varför de inte syns och varför optimering inte är möjlig och så vidare i deras implementation av EPiServer.
Fujifilm är inte en av de kunderna som vi haft problem med.
Hej Jimmy. Jo, jag ser problemet. Men det skulle underlätta om du ville svara på vad Jajjas ”16 kriterier” är?
Och vilka EPiServer kunder ni har?
Hej Jimmy. Jo, jag ser problemet. Men det skulle underlätta om du ville svara på vad Jajjas ”16 kriterier” är?
Och vilka EPiServer kunder ni har?
Hej Martin,
Tyckte kriterierna framgick rätt tydligt i PDF:en?
Skalan är för title, description och keywords handlar om de vanligaste fallen vi stött på från att det inte finns något alls och inte går att sätta något till att det går att manuellt sätta _och_ att det genereras utifrån regler man skriver i mallarna ifall inget manuellt finns inskrivet. Hoppas jag inte rörde till det där, är sent på dagen nu. Men det handlar om att det finns olika nivåer på hur sökmotoroptimerat ett CMS är gällande titlar, description och keywords medan övriga data är mer ja/nej på om det finns eller inte.
Sen känns det mer som du frågar för att använda kriterierna tillsammans med Nikke för att göra en egen kravspec. Nikke skriver ju dock ”De kriterier som Jajja har ställt upp för betygsbedömning är bra och inspirerar” så ni har ju redan våra kriterier att utgå ifrån =).
Vi/jag kommer inte att gå ut med vilka EPiServer kunder vi har. Håller däremot gärna teoretiska diskussioner om implementationer och varianter av EPiServer.
Hej Martin,
Tyckte kriterierna framgick rätt tydligt i PDF:en?
Skalan är för title, description och keywords handlar om de vanligaste fallen vi stött på från att det inte finns något alls och inte går att sätta något till att det går att manuellt sätta _och_ att det genereras utifrån regler man skriver i mallarna ifall inget manuellt finns inskrivet. Hoppas jag inte rörde till det där, är sent på dagen nu. Men det handlar om att det finns olika nivåer på hur sökmotoroptimerat ett CMS är gällande titlar, description och keywords medan övriga data är mer ja/nej på om det finns eller inte.
Sen känns det mer som du frågar för att använda kriterierna tillsammans med Nikke för att göra en egen kravspec. Nikke skriver ju dock ”De kriterier som Jajja har ställt upp för betygsbedömning är bra och inspirerar” så ni har ju redan våra kriterier att utgå ifrån =).
Vi/jag kommer inte att gå ut med vilka EPiServer kunder vi har. Håller däremot gärna teoretiska diskussioner om implementationer och varianter av EPiServer.
Hej Martin,
Tyckte kriterierna framgick rätt tydligt i PDF:en?
Skalan är för title, description och keywords handlar om de vanligaste fallen vi stött på från att det inte finns något alls och inte går att sätta något till att det går att manuellt sätta _och_ att det genereras utifrån regler man skriver i mallarna ifall inget manuellt finns inskrivet. Hoppas jag inte rörde till det där, är sent på dagen nu. Men det handlar om att det finns olika nivåer på hur sökmotoroptimerat ett CMS är gällande titlar, description och keywords medan övriga data är mer ja/nej på om det finns eller inte.
Sen känns det mer som du frågar för att använda kriterierna tillsammans med Nikke för att göra en egen kravspec. Nikke skriver ju dock ”De kriterier som Jajja har ställt upp för betygsbedömning är bra och inspirerar” så ni har ju redan våra kriterier att utgå ifrån =).
Vi/jag kommer inte att gå ut med vilka EPiServer kunder vi har. Håller däremot gärna teoretiska diskussioner om implementationer och varianter av EPiServer.
Så mycket ska inte benchmarkas, det är ingen rocketscience att fråga efter H1:or :) Men som jag bloggade på annan plats, har själv tagit fram “kravspecifikationer” med ett gäng frågor som rör just SEO (för mer se http://edenstrom.wordpress.com/2008/05/21/cms-upphandling-och-utvardering/). De flesta större CMS-köparna (webbsystem/budget 10Mkr+ per år) efterfrågar detta vid nyinstallationer. Så har det sett ut sedan, säg 2004.
Så det är inget jag och/eller Nikke ska göra på egen hand. Det ska göras för kund och förslagsvis vara debiterbar tid.
Ska ni göra en v1.1-lista eller en v2.0 för 2009 tror jag det är bra om du hittar och redogör för de webbplatser ni tagit med i undersökningen. Då skulle du slippa svara på bra och dåliga frågor på alla bloggar och nyhetssajter. Antar det tar en del av din tid just nu.
Så mycket ska inte benchmarkas, det är ingen rocketscience att fråga efter H1:or :) Men som jag bloggade på annan plats, har själv tagit fram “kravspecifikationer” med ett gäng frågor som rör just SEO (för mer se http://edenstrom.wordpress.com/2008/05/21/cms-upphandling-och-utvardering/). De flesta större CMS-köparna (webbsystem/budget 10Mkr+ per år) efterfrågar detta vid nyinstallationer. Så har det sett ut sedan, säg 2004.
Så det är inget jag och/eller Nikke ska göra på egen hand. Det ska göras för kund och förslagsvis vara debiterbar tid.
Ska ni göra en v1.1-lista eller en v2.0 för 2009 tror jag det är bra om du hittar och redogör för de webbplatser ni tagit med i undersökningen. Då skulle du slippa svara på bra och dåliga frågor på alla bloggar och nyhetssajter. Antar det tar en del av din tid just nu.
Nä utvärderingar är sällan rocketscience. Det handlar ju mer om att sammanställa data på ett bra ett bra sätt.
Tittade lite på bilden du hade i det inlägget. Och på bilden såg det ut att delar av dina frågor rör ifall det fanns en WYSIWYG-editorer till verktyget?
Och då är frågan är det verkligen ett SEO-kriterium eller inte? För mig är det inte. Det handlar istället om användarvänlighet så är det ett helt annat upplägg som måste göras. Då är det inte längre en listning av funktionalitet, vissa delar av att ranka användarvänlighet riskerar att bli väldigt subjektiva. Men har man en budget på 10Mkr+ per år så förstår jag att du avser att ha ett heltäckande underlag, där då det vi gjort blir en del av underlag men långt ifrån hela.
Vi ser alltså vår utvärdering som ett komplement som bör vara med när man tittar på nya verktyg.
Självklart kommer det komma en ny utvärdering och lika självklart kommer vi först att ta till oss alla erfarenheter vi kan utifrån denna.
Att redovisa webbplatser ser jag inte behovet av riktigt då det är verktygen och funktionaliteten som är viktig.
Man ser sällan utifrån på en webbplats vilka funktioner som finns i verktyget som används. I vissa fall finns det ju spår i koden man kan tolka och avgöra vilket verktyg det gäller och ännu mer sällsynta fall så kan man se exakta möjligheter. Men ofta handlar ju också möjligheterna om vilka rättigheter man får och vilka typer av inlogg till systemen.
Så därför ligger vårt fokus på verktygen i sig och helt frikopplat från hemsidor. Men som jag skrev ovan så samlar vi alla synpunkter vi hittar och diskuterar dem. Så även om jag själv inte ser något behov kanske någon annan gör det, får se jag kanske återkommer på ämnet.
Den tid jag lägger på bloggar och att kommentera det hela är faktiskt mycket mindre än vad jag hade trott att den skulle vara. Och själv tycker jag om en debatt, det är uppfriskande så länge den håller sig på en konstruktiv nivå.
Nä utvärderingar är sällan rocketscience. Det handlar ju mer om att sammanställa data på ett bra ett bra sätt.
Tittade lite på bilden du hade i det inlägget. Och på bilden såg det ut att delar av dina frågor rör ifall det fanns en WYSIWYG-editorer till verktyget?
Och då är frågan är det verkligen ett SEO-kriterium eller inte? För mig är det inte. Det handlar istället om användarvänlighet så är det ett helt annat upplägg som måste göras. Då är det inte längre en listning av funktionalitet, vissa delar av att ranka användarvänlighet riskerar att bli väldigt subjektiva. Men har man en budget på 10Mkr+ per år så förstår jag att du avser att ha ett heltäckande underlag, där då det vi gjort blir en del av underlag men långt ifrån hela.
Vi ser alltså vår utvärdering som ett komplement som bör vara med när man tittar på nya verktyg.
Självklart kommer det komma en ny utvärdering och lika självklart kommer vi först att ta till oss alla erfarenheter vi kan utifrån denna.
Att redovisa webbplatser ser jag inte behovet av riktigt då det är verktygen och funktionaliteten som är viktig.
Man ser sällan utifrån på en webbplats vilka funktioner som finns i verktyget som används. I vissa fall finns det ju spår i koden man kan tolka och avgöra vilket verktyg det gäller och ännu mer sällsynta fall så kan man se exakta möjligheter. Men ofta handlar ju också möjligheterna om vilka rättigheter man får och vilka typer av inlogg till systemen.
Så därför ligger vårt fokus på verktygen i sig och helt frikopplat från hemsidor. Men som jag skrev ovan så samlar vi alla synpunkter vi hittar och diskuterar dem. Så även om jag själv inte ser något behov kanske någon annan gör det, får se jag kanske återkommer på ämnet.
Den tid jag lägger på bloggar och att kommentera det hela är faktiskt mycket mindre än vad jag hade trott att den skulle vara. Och själv tycker jag om en debatt, det är uppfriskande så länge den håller sig på en konstruktiv nivå.
Att EPiServer eventuellt, för det är väl knappast fastslaget som sanning, skulle kunna vara orsak till sämre webbplatser ur ett SEO-perspektiv tror jag kan bero på att EpiServer har använts i stor utsträckning av kommuner och landsting där SEO tidigare inte varit något man bekymrat sig så mycket om.
Utvecklingen har ofta gjorts av större IT-konsultföretag där man är duktig på att utveckla men kanske inte har så stor fokus på resten av webben (tillgänglighet och validerad kod har varit viktigast eftersom det är det kunden frågat efter).
Mindre system däremot som skapas med hjälp av Open Source CMSer utvecklas av entusiaster som brinner för webben och som hänger med i allt som händer bl.a. inom SEO.
Min lite fördomsfulla slutsats är att det vore naturligt om det finns fler dåligt sökmotoroptimerade webbplatser skapade i EPiServer än i andra CMS helt enkelt för att det finns färre duktiga utvecklare som behärskar SEO och färre projektledare som förstått vikten av SEO.
Allt hänger på konsulten och inte på EPiServer.
Att EPiServer eventuellt, för det är väl knappast fastslaget som sanning, skulle kunna vara orsak till sämre webbplatser ur ett SEO-perspektiv tror jag kan bero på att EpiServer har använts i stor utsträckning av kommuner och landsting där SEO tidigare inte varit något man bekymrat sig så mycket om.
Utvecklingen har ofta gjorts av större IT-konsultföretag där man är duktig på att utveckla men kanske inte har så stor fokus på resten av webben (tillgänglighet och validerad kod har varit viktigast eftersom det är det kunden frågat efter).
Mindre system däremot som skapas med hjälp av Open Source CMSer utvecklas av entusiaster som brinner för webben och som hänger med i allt som händer bl.a. inom SEO.
Min lite fördomsfulla slutsats är att det vore naturligt om det finns fler dåligt sökmotoroptimerade webbplatser skapade i EPiServer än i andra CMS helt enkelt för att det finns färre duktiga utvecklare som behärskar SEO och färre projektledare som förstått vikten av SEO.
Allt hänger på konsulten och inte på EPiServer.