Google Merchant Center Prispolicyfel och Lösningar

Google Merchant Center prispolicyfel uppstår när priset som skickas i din produktfeed inte matchar priset som visas på produktsidan eller vid betalning. Den snabbaste lösningen är att se till att priset i feeden, priset på produktsidan, strukturerade data, valuta, moms/fraktvisning och rabattregler är konsekventa, och sedan skicka produkterna för en ny genomsökning i Merchant Center. Utan att åtgärda detta fel kan dina produkter begränsas i Shopping-fliken, gratis listningar eller Performance Max-kampanjer.

På e-handelswebbplatser finns prisinformation inte på ett ställe. Temat, ERP-integrationer, marknadsplatsmoduler, kampanjtillägg, kupongsystem, variationsfält, prisuppdateringar baserat på lagerstatus och Google feed-tillägg kan alla generera olika priser. Google baserar sig på det verkliga priset som visas för användaren. Det vill säga, att skicka 999 SEK i feeden och visa 1.049 SEK på produktsidan, lägga till moms vid betalning eller införa en obligatorisk servicetaxa i korgen kan anses vara ett brott mot prispolicyn.

I denna guide hittar du orsakerna till fel i Merchant Centers prispolicy, hur du identifierar dem med verkliga scenarier och de tekniska steg som krävs för en permanent lösning. Vi har även inkluderat användbara checklistor, särskilt för webbplatser som använder WooCommerce, OpenCart, Shopify, specialanpassad programvara och API-baserade feeds. För en solid infrastruktur är det också viktigt att dina produktsidor fungerar snabbt, är tillgängliga och säkra; här kan E-handelshostinglösningar och SSL-certifikat sidor ge tekniskt stöd.

Vad är ett Google Merchant Center-prispolicyfel?

Ett prispolicyfel uppstår när Google finner en inkonsekvens mellan det pris som lovas till användaren och det som bekräftas på webbplatsen. Denna inkonsekvens kan ibland vara så liten som några ören, eller så tydlig som att det normala priset istället för det rabatterade priset skickas. Google bedömer att priset är ett av de mest känsliga datan för användaren, eftersom det direkt påverkar köpet.

Merchant Center ger vanligtvis följande typer av varningar: prisöverensstämmelse, valutakonflikter, priset på landningssidan matchar inte feedpriset, priset ökar vid betalning, felaktigt försäljningspris, ogiltigt pris i strukturerade data eller automatiska uppdateringar som ändrar priset. Även om felens namn kan variera, är det grundläggande problemet oftast detsamma: priset som Google-boten ser är inte detsamma som price eller sale_price fälten i produktfeed.

Google gör inte denna kontroll endast vid första uppladdningen. Dina produkter genomsöks regelbundet. En produkt som idag är godkänd kan avvisas imorgon på grund av kampanjens slutdatum, valutauppdateringar, lagerändringar eller fel i tillägg. Därför är lösningen inte bara att åtgärda den felaktiga produkten utan att skapa ett system som hanterar prisdata konsekvent från början till slut.

De vanligaste prispolicyfelen

1. Skillnad mellan priset i feeden och priset på produktsidan

I det mest förekommande scenariot är priset i feeden inte detsamma som priset på landningssidan. Till exempel om ett par skor i feeden visas som 749,90 SEK, men på webbplatsen som 799,90 SEK. Denna skillnad uppstår vanligtvis på grund av cache, kampanjtillägg, manuell prisuppdatering eller att feeden drar gammal data.

För att lösa detta bör du först kontrollera det skickade priset i produktens detaljer i Merchant Center. Öppna sedan produktens URL i en inkognitoflik, uppdatera sidan utan cache och notera hur priset visas för användaren. Om du använder CDN eller sidcache, se till att rensa cachen automatiskt efter prisuppdateringar. För webbplatser som använder WordPress/WooCommerce är det säkrare att ställa in uppdateringsfrekvensen för feed-tillägget till minst en gång per dag, och 1-4 timmar under hektiska kampanjperioder.

2. Felaktig överföring av rabatterat pris

För rabatterat pris i Merchant Center är två fält viktiga: price representerar det normala priset, medan sale_price representerar det aktuella rabatterade priset. Om produkten har sänkts från 599 SEK till 499 SEK, bör feeden ha price som 599 SEK och sale_price som 499 SEK. Men många butiker skickar bara 599 SEK i feeden eller rensar inte sale_price-fältet när rabatten har tagit slut.

Om du använder rabatterat pris är det också bra att skicka start- och slutdatum för kampanjen med sale_price_effective_date fältet. Detta fält är inte obligatoriskt, men hjälper Google att korrekt tolka priset. Om feeden inte uppdateras när kampanjen avslutas, kan användaren se 599 SEK på produktsidan medan Google fortfarande förväntar sig 499 SEK, vilket kan leda till ett prisfel.

3. Moms, skatter och obligatoriska avgifter som läggs till senare

I Sverige förväntas det att det pris som visas för konsumenten på e-handelswebbplatser inkluderar moms. Om en produkt som visas som 1.000 SEK på produktsidan blir 1.200 SEK med moms vid betalning, är detta en tydlig prisinkonsekvens. På samma sätt, om obligatorisk paketering, serviceavgifter eller transaktionskostnader automatiskt läggs till i korgen, bör dessa belopp inkluderas i produktpriset eller i den tydligt angivna fraktkostnaden.

För Google är det viktiga kriteriet det faktiska belopp som användaren måste betala för att köpa produkten. Valfria tjänster som presentinslagning, snabb leverans eller extra garantier bedöms annorlunda; men alla obligatoriska avgifter som användaren inte kan undvika att betala påverkar prisuppfattningen. Därför bör den slutliga prisapproachen inkludera moms mellan produktsidan, feed och betalningssteget.

4. Valuta- och formatfel

Priset i feeden bör skickas i ISO 4217-format. För Sverige är det korrekta formatet vanligtvis SEK. Att bara skriva SEK, använda symboler, felaktigt formatera punkter och kommatecken eller visa USD på produktsidan medan man skickar SEK i feeden kan leda till fel.

Exempel på korrekt värde: 1299.90 SEK. För decimalavskiljare är det säkrare att använda punkt beroende på ditt feedformat. Du kan visa 1.299,90 SEK för användaren på webbplatsen, men den strukturerade datan och feeden måste ha ett tydligt format som Google kan läsa. För webbplatser som använder flera valutor bör också landets mål, hreflang och valutajusteringar kontrolleras. Om du gör internationella försäljningar är Domänhantering och landändelser också viktigt för att bygga förtroende på målmarknaden.

5. Förvirring kring variationspriser

Prisskillnader förekommer ofta på produkter med färg, storlek, kapacitet eller paketalternativ. Till exempel kan ett svart mobilskal kosta 199 SEK medan lädermodellen kostar 299 SEK. Om feeden skickar huvudprodukten som 199 SEK, men URL:en öppnas med den förvalda variationen som 299 SEK, kan Google upptäcka en prisinkonsekvens.

I detta fall bör varje variation ha ett unikt produkt-ID, korrekt item_group_id, rätt URL-parametrar och en landningssida som visar den aktuella variationens pris. När användaren klickar på den variation som visas i feeden bör samma variation vara vald när sidan öppnas. Särskilt för butiker som använder specialanpassad programvara är det viktigt att variationers URL:er är genomsökningsbara och inte visar olika priser för botarna.

6. Inkonsekvens mellan strukturerad data och visat pris

Google kan läsa inte bara texten som visas på skärmen, utan också schema.org Product och Offer-markeringarna på sidan. Om det står 899 SEK på sidan men strukturerade data visar 999 SEK, kan Merchant Center upptäcka en prisinkonsekvens baserat på denna information. Detta problem uppstår ofta på grund av temauppdateringar, cache-tillägg eller gamla schema-moduler.

Kontrollera vilket pris som visas på sidan med Google Rich Results Test och URL Inspection-verktygen. Se till att fälten price, priceCurrency, availability och om nödvändigt priceValidUntil i produkt-schemat är aktuella. Om ditt tema och feed-tillägg drar priser från olika källor, kan det vara bättre på lång sikt att gå över till en enda datakälla för produkten.

Snabb diagnosguide för prisfel

Så här åtgärdar du Google Merchant Center-prispolicyfel steg för steg

Steg 1: Bestäm omfattningen av felet

Först förstå om problemet är på en enskild produkt, en viss kategori eller i hela katalogen. Exportera avvisade produkter genom att filtrera i avsnittet Produkter i Merchant Center. Välj 10-20 exempelprodukter och jämför priser, URL:er, kategorier, märken, variationer och kampanjstatus. Om problemet finns på alla produkter kan det finnas fel i valuta, skatteinställningar, feedformat eller strukturerade data över hela webbplatsen. Om problemet endast finns på kampanjprodukter, fokusera på sale_price och datumfälten.

Steg 2: Jämför feedvärdet med live-sidan

För varje exempelprodukt, skriv ner tre priser bredvid varandra: feedpriset, priset som visas på produktsidan och priset som visas vid betalning. Om de tre inte stämmer överens är det inte tillräckligt att bara göra en korrigering i Merchant Center. Till exempel, om produktsidan visar 349 SEK, korgen 369 SEK och feeden 349 SEK, kan problemet vara en obligatorisk avgift som lagts till i korgen. Om produktsidan visar 349 SEK, men feeden visar 329 SEK, kan det vara så att feeden är gammal.

Stäng av webbläsarens cache under denna kontroll, använd en inkognitoflik och testa om möjligt från olika IP-adresser eller enheter. Vissa webbplatser kan ändra priser baserat på plats, medlemsstatus eller användarsegment. Google-boten beter sig i de flesta fall som en vanlig besökare; medlemspriser, priser som sänks med kuponger eller rabatter som visas efter inloggning bör inte skickas som feedpriser.

Steg 3: Rensa och standardisera produktfeed

Din feed kan skapas med XML, CSV, Google Sheets, Content API eller e-handelsplugin. Oavsett vilken metod du använder, bör prisfälten matas från en enda källa. Att ha olika priser för samma produkt i ERP, på webbplatsen och i feed-tillägget ökar risken för fel. Definiera en enkel regel för den tekniska avdelningen: produktens aktuella försäljningspris bör genereras från ett enda fält i databasen, med rabattinformation separerat och tidskontrollerad.

• price: Skicka det normala eller aktuella huvudpriset med korrekt valuta.
• sale_price: Använd endast om rabatten verkligen är aktiv.
• sale_price_effective_date: Ange kampanjens start- och slutdatum.
• availability: Håll lagersituationen uppdaterad tillsammans med priset.
• link: Skicka användaren till rätt produkt- eller variationssida.

Steg 4: Kontrollera åtkomsten för web crawling

För att Google ska kunna läsa din sida korrekt måste produktsidorna vara öppna för botar. Produkt-URL:er, CSS och JavaScript-källor bör inte blockeras i robots.txt-filen. Om priset laddas med JavaScript kan Google ibland se ett fördröjt eller felaktigt pris. Om servern är långsam kan boten fånga ett gammalt eller tomt pris innan sidan har behandlats helt.

För att minska felen i Merchant Center, försummar inte sidans hastighet och serverns stabilitet. Även om Googles genomsökningssystem kommer att förbättras till 2026, kan e-handelswebbplatser med långsam, avbruten eller felaktig respons fortfarande ha nackdelar i datavalideringen. Se till att dina produktsidor returnerar statuskod 200 HTTP, att kedjor av 3xx-omdirigeringar är korta och att ditt SSL-certifikat fungerar utan problem. För teknisk grund kan NVMe Hosting och Installation av gratis SSL vara viktiga att överväga.

Steg 5: Uppdatera strukturerad data

Att använda produkt-schema på produktsidorna är fördelaktigt både för organisk synlighet och validering i Merchant Center. Men felaktig schema kan vara mer skadlig än att inte använda schema alls. Kontrollera att prisvariabeln i din temafil kommer från den aktuella produkten. Testa också att schema-priset uppdateras korrekt när den valda variationen ändras på produkter med variationer.

Priset som syns i Rich Results Test bör vara detsamma som det pris som visas för användaren på sidan. Dessutom bör priceCurrency fältet vara en giltig kod som SEK, USD eller EUR. För produkter som inte finns i lager bör fältet availability också anges korrekt; att visa det gamla rabatterade priset för produkter som inte finns i lager påverkar både användarupplevelsen och godkännandet i Merchant Center negativt.

Steg 6: Begär omprövning och genomsökning i Merchant Center

Efter korrigeringar, ladda upp feeden igen eller utlös API-synkronisering. Kontrollera att det senaste skickade priset har uppdaterats i produktens detaljer i Merchant Center. Begär sedan omprövning för de problematiska produkterna. I vissa fall uppdaterar det automatiska systemet inom några timmar, medan det i andra fall kan ta 24-72 timmar. För produkter med hög kampanjbudget är det bra att testa med en liten exempelgrupp innan du gör korrigeringar i stor skala för att förhindra upprepning av massfel.

Särskilda kontroller för olika plattformar

WooCommerce-webbplatser

Priserfel på WooCommerce-webbplatser uppstår oftast på grund av cache, flera valutafunktioner, dynamisk prissättningstillägg eller att feed-tillägget använder gammal data. Kontrollera fälten för normalt pris och rabatterat pris på produktredigeringssidan. Kontrollera också att inställningen för sale price mapping i det använda feed-tillägget är korrekt. Om priserna på produktsidorna ändras beroende på medlemskap eller kupongvillkor, bör du skicka det allmänna användarpriset till feeden.

Om du använder server-sidans cache, se till att de berörda produkt-, kategori- och feed-cachefilerna rensas när produktpriset ändras. WordPress hosting och korrekt cachekonfiguration spelar en avgörande roll i detta avseende.

Shopify och färdiga e-handelslösningar

I färdiga system som Shopify är prisfälten vanligtvis mer organiserade; men multi-marknad, flera valutor och automatiska rabatter kan orsaka fel. Kontrollera målland, valuta och produktvariationer i Google & YouTube-appen. Blanda inte jämförande priser med försäljningspriser. Visa inte automatiskt tillämpade rabatter i feedpriset, eftersom Google kanske inte alltid accepterar rabatter baserade på kuponger som inte kan ses direkt på produktsidan.

Specialanpassad programvara och API-integrationer

För specialanpassad programvara är den bästa strategin att skapa en versionerad och loggad datakälla för produktpriser. Vid varje prisändring bör det finnas en logg över vem, när och vilket pris som ändrades och när det återspeglades i feeden. Om du använder Content API, övervaka framgångsrika svar efter uppdateringar och skriv felkoder till ett centralt loggsystem. Se också till att det inte finns några bot-blockeringar, landsbaserade omdirigeringar eller sessionskrav på den URL som Google hämtar.

Permanenta bra metoder för att förhindra prisinkonsekvenser

Att åtgärda prispolicyfel en gång är inte tillräckligt; det är nödvändigt att etablera en hållbar kontrollmekanism. I stora kataloger kan tusentals priser ändras varje dag. Därför bör en strategi med automatisering, loggning och regelbundna revisioner antas istället för manuell kontroll.

• Planera uppdateringstidpunkten för feeden att köra direkt efter kampanjens början och slut.
• När produktpriserna ändras, rensa cache för sidan, feed och schema samtidigt.
• Kontrollera veckovis prisöverensstämmelsen mellan feed och webbplats för de 50 mest klickade produkterna.
• Dokumentera prisstrategin inklusive moms för alla team.
• Genomför tester för varje variation av produkter med variationer för att säkerställa att rätt priser och URL:er används.
• Övervaka Merchant Centers diagnosrapporter dagligen; om felprocenten överstiger 1%, gör en rotorsaksanalyser.
• Övervaka regelbundet SSL, DNS, hosting och omdirigeringsproblem; oåtkomliga sidor kan påverka prisvalideringen.

Till exempel, om en butik med 5.000 produkter har en daglig prisändringsfrekvens på 8%, bör cirka 400 produkter testas för matchning mellan feed och sida varje dag. Det är orealistiskt att göra hela denna kontroll manuellt. Att producera en rapport med en enkel cron-uppgift som jämför feedpriser med priser som hämtas från live-URL kan även tidigt fånga upp fel.

Hur ska frakt, kuponger och kampanjpriser hanteras?

Fraktkostnaden kan hanteras separat från produktpriser; men dina kargo-inställningar i Merchant Center måste vara korrekta. Att ange gratis frakt på produktsidan och sedan införa fraktkostnader vid betalning undergräver användarens förtroende och kan leda till policyproblem. Om fraktkostnaden varierar beroende på land, stad, volym eller korgens värde, bör du konfigurera dina fraktregler i Merchant Center därefter.

Var försiktig med rabatter vid användning av kuponger. Om användaren måste ange en kupong manuellt bör denna rabatt vanligtvis inte skickas som produktpris i feeden. Om det finns en offentlig, automatisk tillämpad rabatt på webbplatsen kan den definieras som sale_price. Om produkten visas som 699 SEK istället för 799 SEK direkt på sidan och alla användare kan få detta pris, kan 699 SEK användas i feeden. Men att bara ange priset som sänks med kupongen EFSANE10 i feeden kan leda till att Google ser ett annat pris på landningssidan.

När bör Google automatiska produktuppdateringar användas?

Automatiska produktuppdateringar i Merchant Center gör det möjligt för Google att läsa pris- och lagerinformation från din produktsida och tillfälligt åtgärda vissa fel i feeden. Denna funktion kan minska små inkonsekvenser; men det är ingen permanent lösning. Om datan som Google läser är felaktig på grund av fel schema eller fördröjda JavaScript, kan automatiska uppdateringar också ge felaktiga resultat.

Du kan hålla denna funktion aktiverad, men du måste garantera noggrannheten hos din primära datakälla. Automatiska uppdateringar bör ses som en säkerhetsåtgärd för små tidsavvikelser orsakade av gammal feed. Om systemet ständigt gör prisjusteringar, indikerar det att det finns ett grundproblem i dina feedprocesser.

Hur påverkar teknisk infrastruktur prisfel?

Fel i Merchant Centers prispolicy syns oftast i marknadsföringspanelen, men den grundläggande orsaken kan ligga i den tekniska infrastrukturen. Dålig hostingprestanda, frekventa 500-fel, trasig SSL, felaktiga omdirigeringar, automatiska valutaförändringar baserat på land och aggressiva cache-inställningar kan leda till att Google läser priser felaktigt. Det är avgörande för e-handelswebbplatser att produktsidor svarar snabbt och stabilt, inte bara för SEO utan även för godkännande av annonser och synlighet i shopping.

Hostragons erbjuder pålitlig hosting, domänhantering och SSL-lösningar för e-handelsprojekt, vilket hjälper till att stärka denna tekniska grund. Till exempel kan Företags Hosting stödja tillgängligheten av produktsidor under högtrafikperioder, medan Domänöverföring och DNS-hantering kan minska genomsökningsproblem orsakade av felaktiga omdirigeringar. Målet här är inte att pressa försäljningen, utan att tekniskt möjliggöra den pålitliga datastream som Merchant Center behöver.

Checklistan: De sista 12 punkterna innan publicering

• Matchar price-fältet i feeden med priset på produktsidan?
• Används sale_price endast vid aktiva kampanjer?
• Är kampanjens start- och slutdatum korrekta?
• Finns det obligatoriska prisökningar mellan produktsidan och betalningsskärmen?
• Skickas valutan i ISO-format?
• Öppnar variations-URL:en den korrekta variationen?
• Visar produkt-schema det aktuella priset?
• Blockerar robots.txt Googles möjlighet att bearbeta sidan?
• Rensas cachen automatiskt vid prisändringar?
• Är inställningarna för frakt och skatter i Merchant Center korrekta?
• Är priset på mobilversionen detsamma som på desktop-versionen?
• Har feeden skickats på nytt efter korrigeringar?

Vanliga frågor

Hur lång tid tar det att åtgärda ett Google Merchant Center-prispolicyfel?

Att få produkterna godkända igen efter korrigeringar tar vanligtvis mellan några timmar och 72 timmar. Tiden kan variera beroende på antalet produkter, genomsökningsfrekvens, typ av fel och intensiteten av omprövningen.

Hur ska jag skicka det rabatterade priset i feeden?

Det normala priset ska skickas i price-fältet, medan det aktiva rabatterade priset ska skickas i sale_price-fältet. Om kampanjens start- och slutdatum är kända, är det bra att också använda sale_price_effective_date-fältet för att minska felen.

Är det obligatoriskt att visa priser inklusive moms?

För e-handelswebbplatser som säljer till konsumenter i Sverige förväntas priset visas inklusive moms. Att lägga till obligatoriska skatter eller avgifter vid betalning som inte visas på produktsidan kan leda till prisinkonsekvenser i Merchant Center.

Åtgärdar automatiska produktuppdateringar prisfel helt?

Nej. Automatiska produktuppdateringar kan minska små tidsavvikelser, men de löser inte permanent felaktiga feeds, gammalt schema eller felaktig prissättning på webbplatsen. Den primära datakällan måste åtgärdas.

Hur förebygger jag prisfel för produkter med variationer?

Du bör använda rätt pris, unikt produkt-ID, gemensam item_group_id och korrekt landnings-URL för varje variation. När användaren klickar på variationen bör den öppnas med den variation som matchar priset i feeden.

Slutsats

Fel i Google Merchant Centers prispolicy uppstår oftast på grund av små dataskillnader mellan feed, produktsidan, schema och betalningssteget. En permanent lösning kräver en enskild datakälla för priser, korrekt hantering av rabatter, uppdaterade strukturerade data, snabbt genomsökningsbara sidor och en regelbunden revisionsprocess. För att säkerställa att dina produkter visas korrekt i Google Shopping och gratis listningar, försummar du inte din tekniska infrastruktur. Du kan även överväga att granska Hostragons hosting-, domän- och SSL-lösningar för att ge din e-handelswebbplats en mer robust datastream.