Vad kostar en Shopify-butikssökare egentligen 2026?

En butikssökare kan se ut som en engångsfunktion. Du lägger till appen, laddar upp dina butiker, anpassar kartan och sedan fungerar allt. Det som är lätt att missa är att de flesta butikssökare fortsätter att kosta pengar även efter det, tyst i bakgrunden, varje gång en kund använder dem. Kartan på din butikssida är inte en statisk bild, utan en live-tjänst som debiteras per interaktion och skalar med din trafik.

För många Shopify-butiker förblir detta osynligt tills en av tre saker händer: den kostnadsfria kvoten tar slut, en intensiv säsong driver användningen över en gräns, eller en faktura kommer som är högre än någon hade budgeterat för. Den här artikeln förklarar vad som faktiskt driver kostnaden 2026, varför den är lätt att underskatta och vad du kan göra för att hålla den förutsägbar.

Varför en butikssökare är en löpande kostnad, inte en engångskostnad

Anledningen till att en butikssökare kostar pengar löpande är att en enda kundsökning vanligtvis utlöser flera separata betalda API-anrop, inte bara ett. En typisk sökning i en butikssökare sätter i gång ungefär detta i bakgrunden: själva kartan laddas (ett anrop), kunden börjar skriva in en adress och får förslag (autocomplete, ofta flera anrop medan personen skriver), den valda adressen omvandlas till koordinater (geokodning, ett anrop) och avståndet från kunden till varje möjlig butik beräknas (ett anrop, och det blir dyrare ju fler butiker du har).

Var och en av dessa är en separat debiterbar händelse. Därför är tankemodellen "jag betalade för appen, kartan är klar" fel. En mer korrekt modell är snarare att "varje sökning är en liten uppmätt transaktion", och mätaren går snabbare ju mer trafik du har och ju fler platser du listar. Det här är den del som de flesta butiksägare aldrig ser, eftersom appen döljer den bakom ett rent gränssnitt. Kostnaden är verklig, den syns bara inte förrän fakturan gör det.

Vad som faktiskt driver fakturan

Tre faktorer påverkar kostnaden för en butikssökare mer än något annat.

• Sökvolym. Eftersom debiteringen sker per interaktion skalar kostnaden direkt med hur många som använder butikssökaren. Det låter självklart, men det får en obekväm konsekvens: butikssökaren blir som dyrast precis när din butik har som mest att göra. En högsäsong som driver trafik driver också användningen av butikssökaren, så fakturan sticker iväg samtidigt som allt annat.
• Antal butiker. Steget där avståndet mellan kunden och dina butiker beräknas blir dyrare när listan med butiker växer, eftersom fler jämförelser måste göras per sökning. En butik med tre platser och en franchisekedja med trehundra ligger inte i samma kostnadsklass, även vid samma trafik.
• Avbrutna sökningar. Det här är den dolda kostnaden. Adressförslag debiteras medan kunden skriver, och en kund som börjar skriva men sedan avbryter har ändå genererat debiterbara anrop. Vid tillräckligt hög trafik blir avbrutna autocomplete-sessioner en verklig kostnadspost på fakturan som ingen planerade för, just eftersom ingen ser avhoppen.

Så fungerar prismodellen nu

För att förstå fakturan hjälper det att känna till hur den underliggande modellen har förändrats och hur den ser ut i dag.

Fram till början av 2025 gav Google Maps Platform varje konto en fast månatlig kredit på 200 USD som täckte en del av användningen i alla tjänster. Enligt Googles egen pris-FAQ ersattes krediten på 200 USD från och med 1 mars 2025 med en kostnadsfri månatlig användningströskel för varje enskild tjänst, uppdelad i nivåerna Essentials, Pro och Enterprise. De flesta tjänster som en butikssökare använder ligger under Essentials, som ger 10 000 kostnadsfria debiterbara händelser per månad och tjänst.

För butikssökare specifikt blev den praktiska effekten en mindre kostnadsfri kvot. StoreLocatorWidgets, en leverantör av butikssökare, förklarade detta för sina kunder vid den tidpunkten: med den gamla krediten på 200 USD kunde en butikssökare hantera ungefär 25 000 laddningar per månad innan avgifter började tillkomma, medan den nya Essentials-gränsen sänker den siffran till cirka 10 000 laddningar per månad innan den kostnadsfria kvoten är förbrukad.

Googles FAQ ger ett konkret exempel på hur detta förändrar en faktura: en kund som gjorde 20 000 geokodningsförfrågningar per månad betalade 0 USD med den gamla krediten på 200 USD, men får i den nya modellen 10 000 kostnadsfria förfrågningar och debiteras för de övriga 10 000, vilket ger en månadskostnad på cirka 50 USD. Det är en liten summa i sig. Den slutar vara liten när du multiplicerar mönstret över varje tjänst som en butikssökare använder, vid verklig trafik, under en intensiv månad.

Poängen är inte att Google Maps har blivit orimligt dyrt. För en liten butik som ligger tryggt under de kostnadsfria gränserna kanske butikssökaren fortfarande inte kostar någonting. Poängen är att den kostnadsfria bufferten är tunnare än tidigare, och att fakturan skalar med trafik, sökbeteende och antal butiker.

Ytterligare en reservation: om du har ett förhandlat Google Maps-avtal eller en abonnemangsplan för Google Maps Platform kan din debitering skilja sig från standardexemplen med pay-as-you-go ovan. Se dessa exempel som ett sätt att förstå kostnadsmekanismen, inte som en ersättning för att granska din egen faktureringsmodell.

Så håller du kostnaden under kontroll

Kostnaden går att hantera, men bara om den hanteras medvetet. Några praktiska steg:

• Sätt kvotgränser och budgetvarningar. Budgetvarningar hjälper dig att upptäcka när kostnaden stiger, men varningar i sig stoppar inte automatiskt användning eller debitering. För att minska risken för toppar i antalet förfrågningar bör du se över kvotgränserna i Google Maps Platform för de API:er som din butikssökare använder och sätta rimliga tak där det är möjligt.
• Följ upp slutförda sökningar, inte bara totaler. Eftersom avbrutna autocomplete-sessioner debiteras i det tysta visar din andel slutförda sökningar om du betalar för många halvfärdiga sökningar. En låg slutförandegrad är inte bara en UX-signal utan också en kostnadssignal.
• Begränsa dyra anrop till där de verkligen behövs. Alla besökare behöver inte den mest detaljerade och dyraste sökningen. Att begära premiumdata för varje sökning, när bara en del av användarna behöver den, är ett vanligt sätt för fakturan att växa i det tysta.
• Cacha din egen platsdata där det går. Butiksnamn, adresser, öppettider, kontaktuppgifter och annan platsdata som du själv äger ändras sällan mellan sökningar. Om den informationen levereras effektivt minskar behovet av onödiga live-uppslag. Om du cachar API-data från Google Maps Platform bör du först kontrollera Googles villkor och dokumentation, eftersom viss Google-genererad data omfattas av lagringsbegränsningar.

När en butikssökare utan Google Maps API är ett rimligt val

För vissa butiker tippar kalkylen över. Om trafiken till butikssökaren är hög, om butikslistan är stor, om en högsäsong regelbundet driver användningen över den kostnadsfria gränsen, eller om själva oförutsägbarheten i en användningsbaserad faktura är ett problem, då kan det vara värt att överväga en butikssökare som inte är beroende av det betalda Google Maps API:et.

Bytet handlar om förutsägbarhet. En användningsbaserad modell kan vara billig vid låg volym och obekväm vid hög volym, och den innebär alltid en risk för toppar. En modell med en fast, känd kostnad byter bort fördelen med att vara "gratis vid låg volym" mot en faktura som inte överraskar dig och som inte skalar upp bara för att du har en bra trafikmånad. Om du vill förstå alternativen mer i detalj har Progus en separat guide om att driva en store locator without the Google Maps API. För handlare som föredrar förutsägbara kostnader och inte vill hantera en betald Maps API-nyckel är Progus Store Locator byggd för att fungera utan en sådan.

Det här är inte ett påstående om att Google Maps är fel val för alla. För många butiker fungerar det bra, och det är enklare att stanna kvar än att byta. Däremot är kostnaden verklig, den skalar på sätt som är lätta att missa, och den är värd att förstå innan fakturan fattar beslutet åt dig.

Misstag att undvika när du vill kontrollera kostnaden

Det finns några misstag som gör kostnaden för en butikssökare svårare att förutse eller kontrollera.

• Att behandla butikssökaren som en färdig, redan betald funktion. Appavgiften är inte hela kostnaden; API-debiteringen per sökning är det, och den fortsätter så länge butikssökaren används.
• Att förlita sig på budgetvarningar som om de vore ett tak. Budgetvarningar är användbara, men de stoppar inte användning eller debitering av sig själva. För verkligt skydd mot toppar i antalet förfrågningar bör du se över kvotgränserna för de API:er som din butikssökare använder och bestämma hur mycket trafik den ska få hantera innan den kräver uppmärksamhet.
• Att ignorera avbrutna sökningar. Autocomplete debiteras medan kunder skriver, så halvfärdiga sökningar kostar pengar utan att synas som en tydlig rad om du inte aktivt letar efter dem.
• Att anta att gratisnivån är densamma som tidigare. Den kostnadsfria kvoten för butikssökare minskade när krediten på 200 USD ersattes 2025; om du budgeterar utifrån den gamla modellen bäddar du för en överraskning.
• Att begära premiumdata för alla. Detaljerade och dyra uppslag för varje besökare, när bara vissa behöver dem, är ett av de tystaste sätten för en faktura att växa.

Avslutande tankar

En butikssökare är en tillgång du äger, men också en funktion med en verklig och återkommande driftskostnad, inte något du installerar en gång och sedan glömmer. Kostnaden går att hantera, men bara om du behandlar den som just det: förstå vad varje sökning debiteras för, sätt rimliga kvotgränser och budgetvarningar, håll koll på de delar som debiteras i det tysta och vet var din trafik ligger i förhållande till den kostnadsfria gränsen.

För många butiker räcker det, och Google Maps förblir ett bra val. För butiker där fakturan skalar obekvämt med trafiken, eller där förutsägbarhet är viktigare än en gratisnivå vid låg volym, är det värt att utvärdera en butikssökare som fungerar utan en betald Maps API-nyckel innan nästa intensiva månad avgör frågan åt dig.

Progus Store Locator är byggd för handlare som vill ha den typen av förutsägbar lösning: en Shopify-butikssökare som kan köras utan en betald Google Maps API-nyckel, så att kostnaden inte skalar upp med varje trafikintensiv månad.