2.2 On-site-faktorer
2.3.4 WebSite Auditor
SEO Powersuite link-assistant tillhandahåller olika verktyg som kan använ- das för att utvärdera en webbplats. Ett av dessa verktyg är Website Auditor som strävar efter att efterlikna sökmotorernas sätt att söka igenom webbappli- kationer för att hitta och granska alla resurser, både interna och externa så som HTML, CSS, JavaScript, bilder med mera. Samma URL-adresser på webbap- plikationen som finns tillgängliga för en sökmotor analyserar även Website Auditor17. Exempel på information och data som går att hämta med hjälp av verktyget är strukturen av sidan, dels visuellt men också siffror på sidornas djup och hur många länkar det finns till de olika sidorna på sidan. Website Auditor kan också analysera varje URL-adress på webbapplikationen utifrån nyckelord och exempelvis visa på hur många gånger nyckelorden skrivs ut i titlar, meta-tags och inom andra komponenter i HTML-koden. Slutligen ut- värderar även verktyget domänens styrka där det går att hämta information om sidans popularitet på sociala medier och hur mycket trafik som webbap- plikationen genererar.
16 Google, Rapport om genomsökningsstatistik (webbplatser): https://support.
google.com/webmasters/answer/35253?hl=sv&authuser=1&ref_topic= 4610900
3
Metod
Kapitlet redogör för metodiken som används för arbetets utförande. För att kunna replikera arbetet presenteras hur en enkätundersökning utfördes, hur webbapplikationens system är uppbyggd och hur testningen för de olika fak- torerna utfördes.
3.1
Enkätundersökning
För att avgöra vilken sökmotors riktlinjer som var mest lämpliga att följa ge- nomfördes en enkätundersökning (se Bilaga 2: Enkätundersökning sökmo- torvanor). Målet var att få en ökad förståelse för marknadens sökmotorvanor, identifiera den söktjänst som användes i högst grad och utvärdera vad som bi- drar till att användaren klickar på ett sökresultat. Undersökningen var webba- serad och omfattade fem frågor inom ämnet, varav en fråga med svarsskalan 1 till 5 och resterande var slutna frågor med olika alternativ. Undersökningen marknadsfördes i köp- och säljgrupper baserade i olika delar av landet, samt hos studenter vid Linköpings universitet för att ge en diversifierad svarsbild, och den genererade nära 90 svar.
3.2
System
För att det ska vara möjligt att replikera arbetet presenteras de olika verktygen som använts för att utveckla webbapplikationen. Webbshoppens arkitektur är uppdelad i klient- och serversida, hädanefter benämnda frontend respektive backend.
3.3. Testning
3.2.1
Frontend
Klientsidan utgörs i grunden av märkspråket HTML, vilket är ett verktyg för att enkelt bestämma ett dokuments struktur. Tillsammans med detta använ- des en stilmall, CSS, för att definiera utseende och layout. För att underlätta utvecklingen av klientsidan och som en del av att göra den mobilanpassad an- vändes färdiga HTML-komponenter från biblioteket Bootstrap. För att kom- municera med servern användes JavaScript-biblioteket jQuery, vilket använ- des för att skicka förfrågningar till servern och hantera eventuell returdata, för att sedan implementera denna i HTML-format. Vidare användes jQuery även för att enkelt skapa professionella animationer.
3.2.2
Backend
Serversidan är baserad på ramverket Flask, vilket är ett Python-bibliotek ut- vecklat för webbplatser, med stöd för ett brett utbud av tillägg. Flask kommu- nicerar i sin tur med en databas av SQL-format och tillhandahåller data från denna till klientsidan.
3.3
Testning
Utvärderingen genomfördes i fem olika delmoment, där varje del undersök- te en on-site-faktor. De faktorer som utvärderades var nyckelord, hyperlänk- struktur, korskopplingar, breadcrumbs och sitemap. Antalet iterationer som genomfördes för de olika faktorerna berodde av antalet försöksparametrar som undersöktes, alltså olika variationer av en faktor. Utifrån testresultatet kunde sedan slutsatser dras om huruvida faktorerna påverkade sökmotorop- timering och storleken av dess påverkan.
Innan iterationerna påbörjades, testades den initiala webbapplikationen ge- nom att rangordnas av Google. För att Google ska kunna indexera webbap- plikationen krävs en domän och därför köptes Sparket.se. Den initiala versio- nen, utvecklad för att möta de grundläggande funktionella och tekniska krav som förväntas av en e-butik, publicerades på domänen och en begäran skic- kades till Google Search Console om att få sidan indexerad. Eftersom Google Search Console inte meddelar domänens ägare när webbapplikationen är in- dexerad eller hur lång tid det skulle ta, behövdes en metod för att bedöma detta. Om domänen finns att hitta på Google har domänen också blivit index- erad minst en gång av Google. Därför antogs den initiala webbapplikationen vara indexerad då den gick att hitta för något valt sökord. Tre stycken, för vår tjänst, relevanta sökord och kombinationer av dessa användes för att testa hur Google rangordnade webbapplikationen. Flera sökord och kombinationer av dessa testades för att reducera slumpfaktorn, stärka testresultatens validitet och därmed dra säkrare slutsatser. De tre sökorden var: sparket, uthyrning och
3.3. Testning
begagnat. Den initiala webbapplikationens rangordning användes sedan som utgångspunkt för det första testet.
Varje iteration undersökte en försöksparameter av en on-site-faktor och dela- des upp i utveckling och testning. Vid utveckling utformades webbapplika- tionen i enlighet med den försöksparameter som iterationen undersökte. För- söksparametrarna är olika typer av on-site-faktorer som antas påverka Goog- les rangordning. Några försöksparametrar är exempelvis djup och bredd för hyperlänksstruktur eller placeringen av nyckelord. Försöksparametrarna be- stämdes utifrån teori eller genom slumpmässig sökmetod.
Efter utvecklingen publicerades den nya versionen av webbapplikationen på domänen och en ny begäran om indexering skickades till Google. Tolv timmar efter att begäran skickats kontrollerades det om en förändring skett i web- bapplikationens rangordning för ett antal av de valda sökfraserna. Under 36 timmar, då ingen ny förändring publicerats på domänen testades rangord- ningen tre gånger med tolv timmars intervall. Rangordningen förändrades som mest tre placeringar för någon av sökfraserna, vilket fungerande som en riktlinje vid testningen då webbapplikationen antogs vara indexerad när rangordningen förändrats mer än tre placeringar under tolv timmar. Detta då en förändring av sökmotorfaktorer faktiskt förväntas påverka placeringen på Google. Tio sökfraser testades, och att webbapplikationen skulle placeras som mest tre placeringar från föregående placering i ett urval av 150 000 till 1 500 000 träffar för någon av de tio sökfraser då sökmotorfaktorer förändrats ansågs osannolikt.
När Google ansågs ha indexerat webbapplikationen påbörjades testningen, det vill säga undersökning av webbapplikationens placering på Google för de olika sökfraserna. Efter att resultatet noterats upprepades iterationsprocessen för en ny försöksparameter och när alla iterationer för en faktor var avslutade bevarades versionen för den försöksparameter som rangordnades högst på Google. Denna version användes sedan i iterationen av nästa faktor vilket resulterade i en slutgiltig webbapplikation som var mest sökmotoroptimerad med avseende på de valda faktorerna.
3.3.1
Nyckelord
Duplicering av nyckelord
För att testa nyckelordens påverkan och huruvida duplicering av nyckelord är positivt för sökmotoroptimering testades detta under tre iterationer. Den första iterationen utfördes på en version där endast nyckelordet sparket fanns i URL:en. När resultatet hade tagits fram påbörjades iteration 2 där nyckelor- den implementerades enligt Zhang et al. [34]. De tre nyckelorden placerades i title-tag, meta-description-tag och heading 1 i varje HTML-fil. Nedan visas hur nyckelorden implementerades i koden.
3.3. Testning
< t i t l e > S p a r k e t uthyrning begagnat</ t i t l e >
<meta name= " d e s c r i p t i o n " c o n t e n t= "Välkommen a t t köpa begagnat och f å t i l l g ång t i l l uthyrning på s p a r k e t " >
<h1>Välkommen t i l l s p a r k e t , en s i d a f ö r uthyrning och begagnat</h1>
När resultatet från implementeringen av nyckelorden noterats påbörjades ite- ration 3 där alla nyckelord duplicerades och placerades i samma tags som under iteration 2. Nedan visas koden då duplicerats.
< t i t l e > S p a r k e t s p a r k e t uthyrning uthyrning begagnat begagnat</ t i t l e >
<meta name= " d e s c r i p t i o n " c o n t e n t= "Välkommen a t t köpa begagnat begagnat och f å t i l l g ång t i l l uthyrning uthyrning på s p a r k e t s p a r k e t " >
<h1>Välkommen t i l l s p a r k e t s p a r k e t , en s i d a f ö r uthyrning uthyrning och begagnat begagnat</h1>
Nyckelordsdensitet
Då teorin om vilken nyckelordsdensitet som är bäst för att sökmotoroptime- ra en webbplats är tvetydig testades även denna faktor under två iterationer. Under den första iterationen implementerades de tre nyckelorden så att des- sa utgjorde mellan två till fem procent av innehållet på varje HTML-sida. Se Tabell 3.1 nedan.
Nyckelordsdensitet 2-5 % Totalt antal ord Nyckelord Densitet (%)
/homepage 280 12 4,3 /about 136 4 2,9 /search 72 3 4,2 /product/1 122 6 4,9 /product/2 122 6 4,9 /product/3 122 6 4,9 /product/4 122 6 4,9
Tabell 3.1: Nyckelordsdensitet 2-5 % för webbapplikationens samtliga sidor, inklusive fördelning av totalt antal ord och nyckelord
När webbapplikationens position ändrats, ökades antalet nyckelord i förhål- lande till det övriga innehållet på varje HTML-sida. Detta gjordes i syfte att öka nyckelordsdensiteten. Se Tabell 3.2 nedan.
3.3. Testning Nyckelordsdensitet 5-10 % Totalt antal ord Nyckelord Densitet (%)
/index 280 24 8,6 /about 138 20 7,2 /search 75 6 8,0 /product/1 129 12 9,3 /product/2 129 12 9,3 /product/3 129 12 9,3 /product/4 129 12 9,3
Tabell 3.2: Nyckelordsdensitet 5-10 % för webbapplikationens samtliga sidor, inklusive fördelning av totalt antal ord och nyckelord
3.3.2
Struktur
Djup och bredd har enligt teorin 2.2.2 Struktur stor påverkan på sökmotorers bedömning vid indexering. För att undersöka djup och bredd krävdes det att nodernas position i nätverket var entydiga. Detta innebär att endast en eller ingen väg fick förekomma mellan två noder, det vill säga ett nätverk utan korskopplingar. Om det förekom flera vägar mellan två noder som hade oli- ka avstånd, rådde osäkerhet kring vilket skikt noden låg i. Detta resulterade i svårigheter att bestämma nätverkets bredd i olika skikt samt i vissa fall nät- verkets maximala djup. Enligt teorin som presenterades i 2.2.2 Struktur bör en hierarkisk struktur gynna rangordningen av domänen och webbapplika- tionen utformades därför hierarkisk. En hierarkisk struktur tillåter inte fler än en väg mellan två noder och därmed får inte heller flera vägar med samma avstånd mellan två noder förekomma. Eftersom varken flertalet vägar med olika avstånd eller flertalet vägar med samma avstånd får förekomma, fick det endast förekomma en väg mellan två noder i webbapplikationens nätverk. Med variation av djup och bredd vid varje skikt kunde många olika nät- verk konstrueras och undersökas utifrån de sju olika URL-adresserna. URL- adresserna representerades av noder i nätverket där den första noden endast kunde placeras på ett sätt. Detsamma gällde för nod 2 som bara kunde place- ras sammanlänkad med nod 1. För nod 3 fanns det två olika sätt, sammanlän- kad med nod 1 eller med nod 2. Nod 4 kunde sammanlänkas på tre olika sätt, nod 5 på fyra olika sätt, nod 6 på fem olika sätt och slutligen nod 7 som kunde sammanlänkas på sex olika sätt. Nätverket kunde alltså skapas på 720 olika sätt. Inom ramarna för denna rapport var det inte realistiskt att undersöka samtliga variationer, därför valdes slumpmässig sökmetod som testmetod. Den slumpmässiga sökmetoden inleddes med att slumpa nätverkets djup, därefter slumpades en bredd som begränsades av nodantalet sju och den maximala bredden för det aktuella djupet. Vilket skikt som skulle breddas slumpades också, och därefter placerades övriga noder ut genom att slumpa en ny bredd och placering. Om exempelvis djup fyra slumpades fram fanns
3.3. Testning
det två noder kvar att placera ut eftersom alla noder i djup noll till fyra har minst en nod. Bågar drogs därefter till alla noder i ett skikt från en av noder- na i skiktet precis ovanför. För noden i skikt noll gjordes inte detta då den är hierarkins topp och inget övre skikt förekom. Detta resulterade i en entydig struktur och den slumpmässiga sökmetoden upprepades för varje iteration för att ta fram nya strukturer. De framtagna strukturernas utformning för de fyra iterationerna finns att se i Tabell 3.3 nedan och visuellt i Figur 3.2, 3.3, 3.4 och 3.5.
När nyckelorden testades hade nätverket åtta noder då webbapplikatio- nens startsida anropades med både URL-adressen “Sparket.se” och “Spar- ket.se/index”. När strukturerna skulle tas fram genom den slumpmässiga sökmetoden uppstod svårigheter eftersom två olika noder, som egentligen motsvarade samma sida, inte kunde placeras olika eller sammanlänkas med olika noder. URL-adressen “Sparket.se/index” togs därför bort vilket resul- terade i ett nätverk med endast sju noder. Detta nätverk utgjorde webbappli- kationens initiala struktur som testades i den första iterationen och kan ses i Figur 3.1.
Iteration / Noder per skikt 0 1 2 3 4 5 6 Djup Maximal bredd
2 1 2 2 2 0 0 0 3 2
3 1 1 1 1 1 1 1 6 1
4 1 2 4 0 0 0 0 2 4
5 1 1 1 1 3 0 0 4 3
Tabell 3.3: Antal noder per skikt för iteration 2-5, samt djup och maximal bredd för nätverken
3.3. Testning
Figur 3.2: Struktur för iteration 2.2
3.3. Testning
Figur 3.4: Struktur för iteration 2.4
Figur 3.5: Struktur för iteration 2.5
När en iteration av en struktur publicerats på domänen användes verktyget Website Auditor för att verifiera att rätt struktur utvecklats.
3.3.3
Korskopplingar
Nyckeltalet kompakthet är som tidigare nämnt ett mått på korskopplingar i ett nätverk. Nätverket utformades utifrån värden på kompakthet som ökades med jämna intervall mellan varje iteration, eftersom varje båge står för lika stor andel av kompakthetens värde. Tre värden på kompakthet valdes att ut- vecklas i varsin iteration, 0,3 för första iterationen, 0,6 för andra iterationen
3.3. Testning
och 0,9 för tredje iterationen. Från det bestämda värdet på kompakthet beräk- nades antalet bågar som nätverket skulle innehålla med en omskrivning av formeln för kompakthet, se formel 3.1.
ÿ i
ÿ j
cij = Max ´ Cp(Max ´ Min) (3.1)
Beroende på antalet bågar i nätverket som iterationerna för korskopplingarna utgick ifrån, och det beräknade antalet bågar nätverket skulle innehålla, be- hövdes bågar antingen tas bort eller läggas till. För att bestämma mellan vilka noder bågar skulle läggas till eller tas bort, bestämdes först startnod och där- efter slutnod. Behövdes bågar läggas till, valdes nod 1 som första startnod och nod 2 som första slutnod och sedan undersöktes nodernas sammanlänkning. I det fall en båge saknades mellan startnoden och slutnoden sammanlänka- des noderna. Om det istället förekom en båge mellan noderna, valdes nod 3 som slutnod och sammanlänkningen undersöktes. Detta upprepades till dess att sammanlänkningen med nod 7 studerats. När alla bågar från nod 1 var undersökta valdes nod 2 till startnod och upprepningen med att studera sam- manlänkningen med nästa nod i ordningen fortsatte tills antalet beräknade bågar för iterationen var uppfylld. När bågar behövdes tas bort skedde upp- repningen i motsatt ordning det vill säga nod 7 valdes till första startnod och nod 6 till första slutnod.
3.3.4
Breadcrumbs
För att undersöka breadcrumbs betydelse för sökmotoroptimering utfördes ett test med en iteration. Projektgruppen utgick ifrån den, enligt Google, bäs- ta strukturen från föregående iteration och implementerade breadcrumbs på samtliga sidor förutom startsidan. Enligt Googles riktlinjer1placerades länkar till samtliga tidigare sidor i strukturen, vilket medförde att användare kun- de navigera till startsidan och “about”-sidan från alla produktsidor samt att användare kunde navigera till startsidan från “search”-sidan. Strukturen för webbapplikationen med breadcrumbs visas i Figur 3.6.
1Google, Breadcrumbs for SEO: https://developers.google.com/search/
3.3. Testning
Figur 3.6: Struktur för webbapplikationen med breadcrumbs implementerade
Exempel på koden som implementerades på produktsida 1: <ul c l a s s = " breadcrumb " > < l i ><a h r e f= " h t t p ://www. S p a r k e t . se/ " > S p a r k e t . se</a></ l i > < l i ><a h r e f= " h t t p ://www. S p a r k e t . se/about " > About</a></ l i > < l i >Product 1</ l i > </ul>
3.3.5
Sitemap
I enlighet med Googles rekommendation att underlätta för en sökmotors webbcrawler implementerades en sitemap. Sparkets sitemap genererades med hjälp av en webbplats, XML-sitemaps.com2, som kostnadsfritt möjliggör för utvecklare att skapa en sitemap anpassad för deras webbplats.
Sitemapen som genererades beskriver strukturen för Sparkets webbapplika- tion vilket fortsatt är den struktur som visade på högst rangordning vid struk- turtesterna. I Sparkets sitemap-fil finns också information om när den senaste modifieringen gjordes och varje sida tilldelades också ett prioriteringsvärde. Prioriteringsvärdet på en URL-adress ska representera Sparkets utvecklares syn på hur ofta den adressen används och hur viktig den är i relation till andra sidor. Startsidan, Sparket.se, fick med den genererade sitemapen prioritet 1,0.
3.3. Testning
URL-adresserna i skikt 1, “about” och “search”, genererades båda en prioritet på 0,8 och produktsidorna i skikt 2 genererades ett värde på 0,64. “Search” och produktsidorna fick behålla sina prioriteringsvärden men “about” ändrades till 0,5. Det görs alltså ett antagande att en användare av webbapplikationen 100 % av gångerna besöker startsidan, 62 % av gångerna besöker “search”- sidan, 38 % av gångerna besöker “about” och 25 % av gångerna besöker en av de fyra produktsidorna.
Exempel på hur koden i sitemapen ser ut för “search”-sidan: < u r l >
< l o c > h t t p :// s p a r k e t . se/ s e a r c h </ l o c >
<lastmod>2018´04´22T13 : 5 2 : 0 1 + 0 0 : 0 0 </lastmod> < p r i o r i t y > 0 . 8 0 </ p r i o r i t y >
</ u r l >
En robots.txt-fil skapades också och placerades i domänens toppkatalog. Fi- len skapades så att webbcrawlern tilläts att indexera alla sidor som inte kräver inloggning och angav även adressen till Sparkets sitemap. Inloggningssidor- na indexerades dock inte tidigare heller eftersom Googlebot inte genomsöker sidor som kräver registrering och inloggning, om inget annat bestäms av ut- vecklaren. Detta tillägg påverkade alltså inte vilka sidor som indexerades men robots.txt-filen kan trots det vara väsentlig, dels för att assistera sitemapen och dels för att bemöta Googles förfrågan om en robots.txt-fil.
4
Resultat
Nedan presenteras resultaten för samtliga tester och iterationer av de oli- ka on-site-faktorerna. Slutligen visas figurer som representerar resultatet för Sparket.se när den är som mest sökmotoroptimerad.
4.1
Nyckelord
Vid varje iteration av en faktor undersöktes vilken rangordning webbplatsen hamnade på, för att på så vis avgöra betydelsen av varje förändrad faktor. När nyckelordens betydelse skulle undersökas genomfördes fyra iterationer. Iteration 1.1 visade hur webbapplikationen rangordnades initialt innan änd- ringar, då nyckelord endast fanns i domänen samtidigt som nyckelordsdensi- teten låg mellan 2-5 %.
Iteration 1.2 hade nyckelord placerade i tags, samtidigt som nyckelordsdensi- teten hölls på samma nivå som vid föregående test.
Iteration 1.3 undersökte effekten av duplicering av nyckelord i tags, samtidigt som nyckelordsdensiteten ökades till mellan 5-10 %, alltså att nyckelorden utgjorde 5-10 % av det totala innehållet.
I iteration 1.4 förekom ingen duplicering av nyckelord, likt iteration 1.2. Nyc- kelordsdensiteten hölls däremot konstant från föregående iteration genom att öka antalet nyckelord i resterande innehåll, till mellan 5–10 %.
Nedan syns resultatet av de olika iterationerna i Tabell 4.1, där siffrorna repre- senterar webbapplikationens placering bland sökresultatet. En etta innebär alltså att Sparket.se är det första resultatet som visas på sökmotorn.
4.2. Struktur Sökord / Iteration 1.1 1.2 1.3 1.4 Sparket >640 167 >490 153 Begagnat >740 >740 >430 >790 Uthyrning >740 370 >430 >790 Sparket Begagnat >740 18 >490 26 Begagnat Uthyrning >740 245 >490 227 Sparket Uthyrning >740 75 >460 56 Sparket Uthyrning Begagnat >740 1 1 1 Sparket Begagnat Uthyrning >740 3 1 1 Uthyrning Begagnat Sparket >740 3 1 1 Begagnat Uthyrning Sparket >740 2 1 1
Tabell 4.1: Webbapplikationens rangordning på Google med olika placeringar av samt antal nyckelord
4.2
Struktur
Nedan visas webbapplikationens rangordning på Google utifrån fem olika strukturer som först visas i Figur 4.1 till 4.5. Den första iterationen utfördes på den initiala strukturen där URL-adressen “index” tagits bort. Därefter vi- sas resultatet för de fyra strukturer som togs fram via den slumpmässiga sök- metoden. Strukturbilderna är framtagna med verktyget Website Auditor för att bekräfta att rätt struktur har skapats.
4.2. Struktur
Figur 4.2: Struktur för iteration 2.2
4.2. Struktur
Figur 4.4: Struktur för iteration 2.4
Figur 4.5: Struktur för iteration 2.5
Googles rangordning av webbapplikationens utifrån de olika strukturerna re- dovisas i Tabell 4.2 nedan.
4.3. Korskopplingar Sökord / Iteration 2.1 2.2 2.3 2.4 2.5 Sparket 116 123 >480 135 >490 Begagnat >590 >740 >590 >590 >750 Uthyrning >550 >730 >430 306 >720 Sparket Begagnat 18 14 >480 1 >490 Begagnat Uthyrning 219 220 >480 151 >780 Sparket uthyrning 15 15 12 1 13
Sparket Uthyrning Begagnat 1 1 1 1 1
Sparket Begagnat Uthyrning 1 1 1 1 1
Uthyrning Begagnat Sparket 1 1 1 1 1
Begagnat Uthyrning Sparket 1 1 1 1 1
Tabell 4.2: Webbapplikationens rangordning på Google med olika strukturer implementerade
Stratum på alla olika strukturer och motsvarande resultat för sökordet “spar- ket” redovisas i tabellen nedan. Uträkningar för stratum redovisas i Bilaga 4: Distansmatriser.
Iteration Stratum Resultat
2.1 0,14 116 2.2 0,40 123 2.3 1,00 430 2.4 0,31 135 2.5 0,79 430 3.1 0,38 430 3.2 0,10 340 3.3 0,29 430 4.1 0,24 120
Tabell 4.3: Webbapplikationens rangordning på Google för olika stratum med avseende på sökordet “sparket”
4.3
Korskopplingar
Nedan visas resultatet av de olika försöksparametrarna, kompakthet, för an- talet korskopplingar som testats. Testerna genomfördes utifrån strukturen för iteration 2.4 i det förgående testet som vid det tillfället hade kompakthet 0,14, illustrerade i Figur 4.6, 4.7 och 4.8.
4.3. Korskopplingar
Figur 4.6: Kompakthet 0,3 för iteration 3.1
Figur 4.7: Kompakthet 0,6 för iteration 3.2
4.4. Breadcrumbs
Googles rangordning av webbapplikationen utifrån de olika kompaktheterna redovisas i Tabell 4.4 nedan.
Sökord / Iteration 2.4 3.1 3.2 3.3 Sparket 135 >490 >490 340 Begagnat >590 >750 >590 >730 Uthyrning 306 >740 >730 >730 Sparket Begagnat 1 >480 >480 >480 Begagnat Uthyrning 151 >450 >480 >510