Etikettarkiv: indexering

Nu indexeras mobilsidor först av Google

Google indexerar mobilsidor först. Kvinnan på bilden använder mobilen för att söka på Google.

Från och med mars 2018 börjar Google att främst indexera innehållet på mobilsidor. Uppdateringen kallas “Mobile-first indexing” och innebär att Google använder mobilversionen av en hemsida för indexering och ranking. Anledningen är att de allra flesta sökningarna sker från mobilen och att Google strävar efter att ge sina användare (särskilt mobilanvändare) den bästa möjliga sökupplevelsen.

Om din hemsidas design är responsiv och mobilanpassad idag bör du inte påverkas av Googles förändring. Om du däremot har en separat mobilsida för din sajt så är det viktigt att känna till att det främst är innehållet på mobilsidan som kommer att indexeras och rankas av Google framöver.

Google kommer inte att flytta alla sidor på en gång utan börjar med de sidor som redan uppfyller Googles kriterier för mobilanpassning. De vars hemsidor har flyttats kommer att meddelas via Google Search Console.

Tre punkter att se över om du har en separat mobilsida för din sajt:

  1. Se till att innehållet på mobilversionen av din hemsida är likvärdigt med desktopversionen.
  2. När punkt 1 är avbockad, använd Googles robots.txt-testverktyg för att verifiera din mobilsida så att den blir tillgänglig för Googlebot.
  3. Se till att lägga till och verifiera din mobilsida i Google Search Console så att den indexeras av Google.

Läs mer på Google Webmaster Central Blog »


Inte mobilanpassat företagets hemsida än? Här är fyra anledningar att göra det

  1. En majoritet av svenskarna surfar från mobilen varje dag, enligt en rapport från IIS. En mobilanpassad hemsida förbättrar sökupplevelsen för dessa.
  2. Två av tre svenskar tycker att det är viktigt att företag har en mobilanpassad hemsida, enligt rapporten Svenska företag på webben 2017.
  3. Ett företags mobilanpassade hemsida premieras bland Googles mobila sökresultat sedan 2015.

85% surfar från mobilen – här är 5 tips för en mobilanpassad sajt

 

Dela: Facebooktwittergoogle_pluslinkedinmail

Ajax blir sökmotorvänligt

Ajax* är ett samlingsnamn för ett gäng tekniker som webbutvecklare kan använda sig av för att bättra på surfupplevelsen. Det gör det möjligt att ladda nytt innehåll utan att ladda om hela sidan. Används det på rätt sätt så upplevs webbsajten snabbare och kan göras mer lik ett traditionellt program som du kör direkt på din dator (du vet där vi höll till innan vi flyttade oss till molnet). Ajax har fått rejält fotfäste och används ivrigt runt om på nätet, vår kundzon är t ex fullmatad av det.

En gigantisk baksida med tekniken har varit att sökmotorerna inte kunnat indexera Ajax-sidor på ett bra sätt. Och med tanke på hur mycket trafik som drivs genom sökmotorerna vill du ju inte hamna utanför deras synfält.

Nu har dock Google börjat indexera Ajax-sidor för fulla muggar. Riktigt najs – men innan du lutar dig tillbaka och väntar på att din fräcka webbtjänst ska bli indexerad så behöver du kontrollera att du gjort saker på ett sätt som gör Google nöjda. Din kod måste nämligen uppfylla deras villkor för att hamna under luppen. Så surfa först in och kolla deras kom-igång-guide.

Använder du Ajax på din sajt idag? Varför, varför inte?

* Asynchronous JavaScript and XML

Dela: Facebooktwittergoogle_pluslinkedinmail

Säg ja till Google

SEO, Search Engine Optimization, sökmotorsoptimering, sökmotorsvänlig hemsida och länkutbyte (link exchange). Vad är det som avses egentligen med sådan uttryck?

Sammantaget är det olika sätt för att komma högre upp på sökningar hos exempelvis Google.

Om man rådfrågar olika experter om hur man optimerar sin sida gällande just SEO kommer man troligtvis få många vitt skilda svar eftersom det inte är någon exakt vetenskap och dessutom väldigt mycket beror på vad man har för hemsida och resurser att lägga. Företag som aktivt sysslar med sökmotorsoptimeringar försöker på olika sätt få reda på hur sökningar görs hos populära sökmotorer, men de företag som erbjuder sökmotorer, exempelvis Google, är lika ivriga med att förbättra och förändra sökmotorerna för att se till att kvaliteten på sökningen bibehålls och att inte fel sidor får bra placeringar. Exempelvis Google ”straffar” dessutom hemsidor som enligt dem använder fula knep för att få högre placeringar genom att helt eller delvis plocka bort dem från deras sökbara index.

Det jag tänkte gå igenom här är generella riktlinjer man kan ta hänsyn till när man uppdaterar sin hemsida, men vill man ha mer specifika förslag gällande sin hemsida bör man vända sig direkt till ett av de företag som erbjuder sökmotorsoptimering av hemsidor.

Den åtgärd som är absolut enklast att göra är att sätta rätt titlar och beskrivningar på sidorna. I vår kunskapsdatabas har vi beskrivit de vanligaste inställningarna.

Att notera gällande just nyckelord (keywords) är att man ska använda enbart ett fåtal ord och jag rekommenderar att man väljer ut två eller tre ord som är specifika för just den sidan man gör. Även beskrivning (description) ska man vara försiktig att skriva för mycket text i då en rad i princip ska vara tillräcklig som sammanfattning för sidan.

Gällande ALT-inställningen på bilder skall detta inte heller utnyttjas för att få med extra sökord utan det ska vara ett kortare uttryck som beskriver bilden som presenterats. På länkar skall man se till att titlar och länkinformation korrekt avspeglar vad det länkar till och specifikt undvika generella begrepp som ”Klicka här” och ”Läs mer”.

Tillhandahåll helst en översiktsida (Sitemap) av alla sidor på din webbplats eftersom det förenklar möjligheten för sökmotorn att hitta och indexera alla sidor snabbare, särskilt om sidan följer ett visst format. En kortfattad information om Sitemap hittar du även i ett av våra tidigare blogginlägg.

Undvik allt vad flash-hemsidor innebär. De må vara vackra och lättnavigerade, men sökmotorer kan inte indexera flash-filer *. Sökmotorer ser enbart en text-version av din hemsida och tar bort även JavaScript och kommentarer. Det fokuseras alltså på den texten som syns på sidan för att få en korrekt representation om vad besökaren kan tänkas vara intresserad för. Om man därför gör sidan bättre anpassad för användande av textläsare och andra verktyg som normalt används av de med synsvårigheter, exempelvis Braille-terminal som blinda kan använda, förbättrar man även möjligheten för sökmotorer att indexera sidan. Undvik helt att använda table för annat än just tabeller (listningar), istället bör CSS används. W3C har sammanställt en hel del riktlinjer om just användarvänlighet som de kallar för Web Accessibility Initiative (WAI).

Om du använder Firefox finns dessutom tillägget Fangs som försöker presentera sidan som en textläsare skulle se den.

En bok som ofta rekommenderas när det diskuteras hemsidors användarvänlighet är Understanding Accessibility från HiSoftware.

P3P (Platform for Privacy Preference Project) är en annan sak som man bör ta hänsyn till även om det inte direkt hör till sökmotorsoptimeringar. Det är ett sätt att beskriva hur man hanterar integritet på hemsidan men används oftast när man behöver komma ihåg en besökares val mellan olika sidor med hjälp av kakor (cookies). Jag känner inte till någon sökmotor som i dagsläget använder sig av den informationen för att påverka placeringen, men det är oavsett en bra sak att tillhandahålla.

På Wikipedia finns mer information om vad kakor (cookies) är.

Till ens hemsida ska man välja ett bra domännamn som både är besökarevänligt (det ska gå att berätta i telefon) samt att det gärna ska vara sökmotorvänligt. Som sökmotorer ser det separeras ord med bindestreck, så om man har ett domännamn biltvätt.com och någon söker på bil tvätt kanske placeringen blir något lägre än om domännamnet hade varit bil-tvätt.com, men det motsatta är också en möjlighet. Alternativet här är att registrera flera alternativa domännamn som på ett korrekt sätt innehåller de sökord som man vill använda sig av, men jag rekommenderar att man är försiktig här. Ett fåtal domännamn kan säkert hjälpa upp placeringen om man ställer in dem rätt, men man bör absolut inte registrera alla sökord som man kan tänka sig.

Att tänka på är att alla domännamn förutom huvudsidan måste använda en permanent omdirigering (HTTP-status 301) till huvudsidan för att sökmotorer inte ska anse att sidorna konkurrerar om samma utrymme och istället minska huvudsidans placering. I vår LoopiaDNS-tjänst stödjer vi i dagsläget inte permanent omdirigering och inte heller för parkerade domännamn i Loopia Kundzon, men man kan skapa det genom att lägga till domännamn med hemkatalog på UNIX-server och sedan ställa in det med en .htaccess-fil:

RewriteEngine On
RewriteRule .* http://www.loopia.se/%1 [R=permanent,L]

Länkning till ens hemsida är dock mer viktigt när det gäller placeringar då sökmotorer anser att en populär och användbar sida också blir länkad ofta. Undvik dock länkfarmning (en sida med enbart massor med länkar) och intern länkning (samma person, företag eller organisation har flera hemsidor som länkar till varandra) då det har missbrukats och exempelvis Google straffar sådant med mycket sämre placering. En del som sysslar med sökoptimering rekommenderar att man sprider ut hemsidor på olika ip-adresser för att de ska undvika att klassas som intern länkning, men så vitt jag vet räcker inte det utan man behöver ha hemsidor hos olika Internettjänsteleverantörer med egna AS-nummer för att helt undgå den risken. Det jag snarare rekommenderar är kontakta andra företag och organisationer i samma eller liknande bransch och höra om det går att utbyta länkar och information. Notera dock att utbytet ska gynna båda lika mycket för att den man ska kontakta ska acceptera länkutbytet. Det gäller alltså att hemsidan ska vara välbyggd ochuppdaterad med information som kan tillföra något till andras webbplatser.

När någon länkar till ens huvudsida gäller det också att det blir rätt länkat. Om länkningen görs med någon av ens nyckelord som titel kommer sökningar på det nyckelordet lite högre än vad det annars skulle vara. Skillnaden mellan …

<a href="http://kallejohan.example.org">
   Tvättsvamp via kallejohan i Västerås
</a>

… och …

<a href="http://kallejohan.example.org">
   kallejohan
</a>

… kan vara avgörande om man säljer tvättsvamp. Också här gäller att det ska vara korrekt överensstämmande och inte använda sig av generella beskrivningar som ”Klicka här” naturligtvis.

Apropå uppdaterad gillar sökmotorer generellt en sida som är uppdaterad och aktuell, så ofta är det att en blogg eller nyhetsbrev får högre placering på sökmotorer än företagets huvudsida. Tillbakalänkning från bloggen och nyhetsbrev är något som jag absolut rekommenderar, men främst är naturligtvis att hålla hemsidan uppdaterad och aktuell.

Lite länkar som kan hjälpa dig med just ditt hemsidesarbete:

* Vissa sökmotorer som Google kan indexera text från .swf-filer. Dock är detta väsentligt mer begränsat än indexering av webbsidor baserade på HTML och CSS.

Dela: Facebooktwittergoogle_pluslinkedinmail

Jimmys SQL-skola, del 1

Varför har psalmboken innehållsförteckning?

Många av er har säkert varit med om det. En sajt som har fungerat i flera år går plötsligt segt som sirap. Det måste vara något fel på servern. Ingenting har ju ändrats i koden.

Det första man bör tänka i fall som detta, i alla fall med en databasdriven sida (och vilken halvstor sida är inte det på den här sidan av 2000-talet?), är …

Har någon av förutsättningarna, t ex datat, kanske ändrats?

Att leta upp en psalm i ett femsidors häfte utan innehållsförteckning klarar de flesta att göra utan att försämra körens responstid, men när psalmboken växt till 631 sidor så är innehållsförteckningen bra att ha.

Motsvarigheten i databaser är korrekt indexering, vilket är lite av en konstform.

Hur väljer man då sina index för att frågorna ska kunna ställas med rimlig svarstid även med stora mängder data (för vem vill väl inte att order-tabellen ska börja snudda på 10 000-tals rader)?

Det enkla svaret är att det beror på frågorna, men det finns dock ett antal gyllene tumregler som man kan använda sig av för avgöra om en kolumn behöver ett index.

När bör index användas?

Sker det ofta sökningar på kolumnen som returnerar endast ett fåtal av alla rader i tabellen? Isåfall är ett index lämpligt. Detta är psalmboken i ett nötskal. Man frågar …

SELECT * FROM psalms WHERE title =
   'By Babel\'s streams we sat and wept'

… och endast en rad av alla psalmer matchar sökfrågan. Utan index på kolumen title så måste servern söka igenom alla rader tills den hittar psalmen, med index så tar den bara en snabb titt i indexet och hittar rätt psalm direkt.

Är kolumnen en primärnyckel eller en främmande nyckel? Man kan då anta att frågor behöver koppla ihop rader i de bägge tabellerna och därför är det vanligtvis lämpligt att ha index på dessa kolumner. Detta är mest viktigt om man ställer frågor som inte alltid returnerar alla relaterade rader (då servern i sådana fall ändå måste gå igenom alla rader).

Tänk t ex …

SELECT p.title, a.name FROM psalms p INNER JOIN author a ON a.id =
   p.author_id WHERE p.title =
   'By Babel\'s streams we sat and wept'

Utan index på primärnyckeln author.id skulle servern göra:

  • Först slår jag upp psalmtiteln i indexet för p.title.
  • Jag hittade en rad, snabbt som blixten, nu ska jag leta rätt på författaren med hjälp av mitt JOIN-uttryck.
  • Vem är nu author 42? Inte var det första raden i author-tabellen – jag kollar på andra.
  • Inte andra raden heller, jag får kolla på tredje …
  • … osv, till användaren tröttnar och går till den konkurrerande bibel-sajten.

Med index så blir skeendet ett annat:

  • Först slår jag upp psalmtiteln i indexet för p.title.
  • Jag hittade en rad, snabbt som blixten, nu ska jag leta rätt på författaren med hjälp av mitt JOIN-uttryck.
  • Vem är nu author 42? Jag kollar i innehållsförteckningen för author.id. Aha, så hette han.

Kommer vi efterfråga data sorterat efter en viss kolumn? Isåfall är ett index oftast lämpligt (ett så kallat ”clustered index” är att föredra men i MySQL, vilket vi som bekant erbjuder, så får man sådana bara för primärnycklar, eller det första unika indexet utan NULL-värden i InnoDB, med MyISAM så lagras index och data separat, så man kan inte ha data sorterat efter ett index, vilket är definitionen av ett ”clustered index”).

Kommer vi göra begränsande uttryck som består av flera kolumner, men i gengäld reducerar antalet rader i svaret avsevärt? Då är det lämpligt att ha ett kombinerat index på flera av dessa kolumner. Ta t ex:

SELECT p.title, a.name FROM psalms p INNER JOIN author a ON a.id =
   p.author_id WHERE p.title =
   'By Babel\'s streams we sat and wept' AND p.lang = 'en'

här kan ett kombinerat index på p.title och p.lang vara lämpligt:

CREATE INDEX idx_combined_title_lang ON psalms(title, lang)

Dock så får man avväga hur mycket varje extra kolumn reducerar det genomsnittliga antalet rader i svaren. Om man bara har ett språk i databasen så skulle indexet ovan inte vara bättre än det förra på enbart psalms.title. Tvärtom skulle det vara sämre, då det tar upp mer utrymme på disk och ännu värre, mer minne i index-cachen. Det ökar också arbetsmängden som behöver göras varje gång en rad läggs till eller uppdateras i tabellen. Med 300 språk i databasen så är situationen dock kanske en annan (i slutändan så måste man ändå mäta för att vara säker på vad som är lämpligast).

När ska man inte använda index då?

När man aldrig gör sökningar på en kolumn. Då gör man uppdatering och tillägg av data långsammare utan vinst.

När allt data i kolumnen är nästan identiskt. Om man gör sökningar, men sökningarna alltid returnerar ett stort antal rader från tabellen så är inte index lika lämpligt som när begränsningen blir förhållandevis stor.

Om man har en kolumn där antalet rader är högt och radernas data i kolumnen har en hög genomsnittslängd så är det ofta olämpligt att göra ett index på kolumnen då indexet tar upp för mycket minne i index-cachen. Man kan då istället göra ett index på ett några tecken långt prefix för kolumen.

Ett sätt att ta reda på hur långt prefix som är lämpligt är att helt enkelt kolla:

SELECT COUNT(*), SUBSTR(title, 1, 1) AS 'prefix'
   FROM psalms GROUP BY prefix WITH ROLLUP;
SELECT COUNT(*), SUBSTR(title, 1, 2) AS 'prefix'
   FROM psalms GROUP BY prefix WITH ROLLUP;
SELECT COUNT(*), SUBSTR(title, 1, 3) AS 'prefix'
   FROM psalms GROUP BY prefix WITH ROLLUP;

… och så vidare, sedan väljer man den lägsta längd (tredje parametern till SUBSTR) där antalet unika prefix börjar närma sig antalet rader i tabellen. I det optimala fallet så ska alltså antalet rader som frågan ovan returnerar vara värdet för COUNT(*) för ROLLUP-raden (den där prefix=NULL) + 1. Då är alla rader unika i de första N kolumnerna (där N är prefix-längden som användes i frågan). I detta fall har även alla grupper COUNT(*)=1, eftersom det bara är en rad med det prefixet.

Det här är ju jättebra, men hur analyserar jag den här komplicerade frågan?

I MySQL så är EXPLAIN din vän. I manualen så tipsas det om att man bör kolla på de rader i EXPLAIN-utmatningen där key är NULL, där type är range, index eller ALL eller där Extra innehåller ”Using filesort” eller ”Using temporary”.

Dessa rader ger en indikering på vilka tabeller i frågan som söks igenom utan index, vilket allt som oftast ger ett dåligt resultat med mycket data. Det finns även en kolumn som anger hur många rader som fråge-optimeraren uppskattar att servern ska behöva behandla för att ta fram frågeresultatet för tabellen i fråga. Höga värden där (kolumnen heter rows) är ofta synonymt med lång exekvering.

En annan variant, som vi rekommenderar starkt, är att ni skickar in frågor som ni har problem med till oss på askjimmy@loopia.se, så tar vi upp så många som möjligt av dem i nästa del av denna artikelserie. Ni får även gärna skicka in andra luriga frågor av SQL-karaktär så gör jag mitt bästa för att hitta en bra lösning åt er.

Det var allt för den här gången. Tills nästa gång så får jag önska er trevliga JOINs, trevligt aggregerande och all lycka i ert indexeringsarbete.

Dela: Facebooktwittergoogle_pluslinkedinmail