Google Merchant Center-prysbeleidfoute en hoe om dit op te los

Google Merchant Center-prysbeleidfoute ontstaan wanneer die prys wat in jou produkvoedsel gestuur word, nie ooreenstem met die prys wat op die produkbladsy of by die betaalstappe vertoon word nie. Die vinnigste oplossing is om die prys in die voedsel, produkbladsy, gestruktureerde data, geldeenheid, BTW/versendingsvertoning en afslagreëls konsekwent te maak, en dan die produkte binne Merchant Center weer te laat skandeer. As hierdie fout nie opgelos word nie, kan jou produkte beperk word in Shopping-afdelings, gratis lyste of Performance Max-veldtogte.

Op e-handelswebwerwe word prysinligting nie op een plek gehou nie. Tema-sjablone, ERP-integrasies, markplekmodules, veldtog-inproppe, koeponstelsels, variasievelde, voorraadgebaseerde prysopdaterings en Google-voedsel-inproppe kan elk prysdata genereer. Google fokus egter op die prys wat aan die gebruiker vertoon word. Dit beteken dat as jy 999 TRY in die voedsel stuur, maar 1 049 TRY op die produkbladsy wys, of BTW by die betaalskerm byvoeg, of verpligte diensfooie in die mandjie hef, dit as ’n prysbeleid-oortreding beskou kan word.

In hierdie gids sal jy leer wat die oorsake van Merchant Center-prysfoute is, hoe om dit met werklike scenario’s op te spoor, en watter tegniese stappe nodig is vir ’n permanente oplossing. Ons het veral toepaslike kontrolelyste bygevoeg vir WooCommerce, OpenCart, Shopify, spesiale sagteware en API-gebaseerde voedselgebruikers. ’n Stewige infrastruktuur vereis ook dat jou produkbladsye vinnig, toeganklik en veilig funksioneer; op hierdie gebied kan ons bladsye oor Oplossings vir e-handel hosting en SSL sertifika jou tegnies ondersteun.

Wat is ’n Google Merchant Center-prysbeleidfout?

’n Prysbeleidfout gebeur wanneer Google ’n inkonsekwensie vind tussen die prys wat aan die gebruiker belowe word en die prys wat op jou webwerf bevestig word. Hierdie verskil kan so klein wees soos ’n paar sent weens afrondings, of so groot soos ’n normale prys wat in plaas van ’n afslagprys gestuur word. Google beskou prys as een van die sensitiefste datavelde omdat dit ’n direkte uitwerking op koopbesluite het.

Merchant Center gee dikwels waarskuwings soos: prysverskil, geldeenheidsverskil, prys op landingsblad stem nie ooreen met die voedselprys nie, prys styg tydens betaling, foute in afslagprys, ongeldig gestruktureerde prysdata, of outomatiese opdatering wat prys verander het. Al lyk die foutnaam anders, is die kernprobleem meestal dieselfde: die prys wat die Google-bot sien, stem nie ooreen met die price of sale_price veld in die produkvoedsel nie.

Google doen hierdie kontrole nie net by eerste laai nie. Jou produkte word gereeld hergeskandeer. ’n Produk wat vandag goedgekeur is, kan môre verwerp word as gevolg van ’n beëindigde veldtog, wisselkoersopdatering, voorraadverandering of ’n inpropfout. Daarom is die oplossing nie net om die foutiewe produk reg te stel nie, maar om ’n stelsel te hê wat prysdata van begin tot einde konsekwent bestuur.

Die mees algemene prysbeleidfoute

1. Verskil tussen voedselprys en produkbladsyprys

Die mees algemene scenario is dat die prys in die voedsel nie ooreenstem met die prys op die landingsbladsy nie. Byvoorbeeld, ’n skoen word in die voedsel as 749,90 TRY gestuur, maar op die webwerf as 799,90 TRY vertoon. Hierdie verskil ontstaan dikwels as gevolg van kas, veldtog-inprop, handmatige prysopdatering of ’n ou voedsel wat gebruik word.

Om dit op te los, kyk eers na die prys wat in Merchant Center se produkbesonderhede gestuur word. Maak dan die produk-URL in ’n privaat blaaiervenster oop, herlaai die bladsy sonder kas, en neem kennis hoe die prys aan gebruikers vertoon word. As jy ’n CDN of bladsykas gebruik, moet jy die kas outomaties skoonmaak na prysopdaterings. Vir WordPress/WooCommerce-webwerwe word dit aanbeveel om die voedsel-inprop minstens een keer per dag op te dateer, en tydens druk veldtogte elke 1 tot 4 uur.

2. Verkeerde afslagprys in die voedsel

In Merchant Center is daar twee belangrike velde vir afslagpryse: price is die normale prys, en sale_price is die geldige afslagprys. As ’n produk vanaf 599 TRY na 499 TRY afprys, moet die voedsel price 599 TRY en sale_price 499 TRY wees. Baie winkels stuur egter net 599 TRY, of verwyder nie die sale_price veld as die afslag verstryk het nie.

As jy afslagpryse gebruik, is dit nuttig om die begin- en einddatums van die veldtog ook te stuur met die sale_price_effective_date veld. Dit is nie verpligtend nie, maar help Google om die prys korrek te interpreteer. As die voedsel nie opgedateer word nadat die veldtog geëindig het nie, kan Google steeds die laer afslagprys verwag, selfs al sien die gebruiker die hoër prys, wat ’n prysfout veroorsaak.

3. BTW, belasting en verpligte fooie wat later bygevoeg word

Op Turkse e-handelswebwerwe word verwag dat die prys aan die verbruiker BTW ingesluit het. As ’n produk op die produkbladsy 1 000 TRY kos, maar by betaling met BTW 1 200 TRY beloop, is dit ’n duidelike prysinconsekwentheid. Net so, as verpligte verpakking-, diens- of transaksiefooie outomaties in die mandjie gevoeg word, moet dit in die produkprys of duidelik in die versendings-/fooistruktuur ingesluit wees.

Vir Google is die belangrikste maatstaf die werklike bedrag wat die gebruiker moet betaal om die produk te koop. Opsionele geskenkverpakking, vinnige aflewering of ekstra waarborg kan anders hanteer word, maar alle verpligte fooie wat die gebruiker moet betaal, verander die pryspersepsie. Daarom moet die finale prys, BTW ingesluit, konsekwent wees tussen produkbladsy, voedsel en betalingstappe.

4. Geldeenheid- en formaatfoute

Die voedselprys moet die geldeenheid in ISO 4217-formaat hê. Vir Turkye is dit gewoonlik TRY. Net "TL" skryf, simbole gebruik, komma en punt verkeerd plaas, of op die produkbladsy USD wys maar TRY in die voedsel stuur, kan foute veroorsaak.

’n Voorbeeld van ’n korrekte waarde is 1299.90 TRY. Dit is veiliger om ’n punt as desimale skeier in die voedsel te gebruik. Op die webwerf kan jy gebruikers 1.299,90 TL wys, maar die gestruktureerde data en voedsel moet die formaat hê wat Google maklik kan lees. Vir webwerwe met meervoudige geldeenhede moet landedoelwitte, hreflang en geldeenheidkorreksies sorgvuldig beheer word. As jy internasionaal verkoop, is Domein bestuur en land uitbreidings ook belangrik vir markvertroue.

5. Verwarende variasiepryse

Produkte met kleur, grootte, kapasiteit of pakkie-opsies het dikwels verskillende pryse. Byvoorbeeld, ’n swart selfoonkas kos 199 TRY, terwyl die leerweergawe 299 TRY kos. As die hoofproduk in die voedsel 199 TRY is, maar die standaard variasie op die URL 299 TRY is, kan Google ’n prysverskil vind.

Hierdie geval vereis dat elke variasie ’n aparte produk-ID, die korrekte item_group_id, die regte URL-parameter en ’n landingsblad met die variasieprys het. Wanneer die gebruiker op ’n variasie in die voedsel klik, moet dieselfde variasie gekies wees wanneer die bladsy oopmaak. Veral winkels met spesiale sagteware moet sorg dat variasie-URL’s deur bots gescan kan word en nie verskillende pryse vertoon nie.

6. Onversoenbaarheid tussen gestruktureerde data en visuele prys

Google lees nie net die prysteks op die bladsy nie, maar ook die schema.org Product en Offer merkdata. As die bladsy 899 TRY wys, maar die gestruktureerde data 999 TRY het, kan Merchant Center dit as ’n prysverskil beskou. Hierdie probleem gebeur dikwels na tema-opdaterings, kas-inproppe of ou schema-modules.

Gebruik Google Rich Results Test en URL Inspection om te sien watter prys die bladsy aan Google gee. Maak seker dat die Product schema se price, priceCurrency, availability en indien nodig priceValidUntil velde opgedateer is. As jou tema en voedsel-inprop pryse van verskillende bronne haal, is dit beter om op die lang termyn net een produkdatabron te gebruik.

Vinnige diagnose tabel vir prysfoute

Stap-vir-stap hoe om Google Merchant Center-prysbeleidfoute op te los

Stap 1: Bepaal die omvang van die probleem

Vind uit of die probleem net by een produk, ’n spesifieke kategorie, of die hele katalogus voorkom. Gebruik die filter in Merchant Center se Produkte-afdeling om verwerpte produkte uit te voer. Kies 10-20 voorbeeldprodukte en vergelyk prys, URL, kategorie, handelsmerk, variasies en veldtogstatus. As die probleem by alle produkte voorkom, kan dit ’n geldeenheid-, belasting-, voedselformaat- of algemene schema-fout wees. As dit net by veldtogprodukte is, fokus op sale_price en die datums.

Stap 2: Vergelyk voedselprys met lewende produkbladsy

Skryf vir elke voorbeeldproduk die voedselprys, die prys op die produkbladsy en die prys tydens betaling langs mekaar neer. As al drie nie ooreenstem nie, is dit nie genoeg om net in Merchant Center reg te stel nie. Byvoorbeeld, as die produkbladsy 349 TRY wys, mandjie 369 TRY, en voedsel 349 TRY, is die probleem moontlik ’n verpligte fooi in die mandjie. As die produkbladsy 349 TRY wys maar die voedsel steeds 329 TRY het, is die voedsel verouderd.

Voer hierdie toets handmatig uit met kas afgeskakel, in ’n privaat venster, en indien moontlik vanaf verskillende IP’s of toestelle. Sommige webwerwe wys pryse afhangende van ligging, lidmaatskap of gebruikersegmente. Google-bots werk meestal soos ’n gewone besoeker; lidmaatskappryse, koeponafslag of spyskaarte vir aangemelde gebruikers moet nie as voedselprys gestuur word nie.

Stap 3: Maak die produkvoedsel skoon en standaardiseer dit

Jou voedsel kan in XML, CSV, Google Sheets, Content API of via ’n e-handels-inprop geskep word. Ongeag die metode, moet prysvelde van een enkele databron kom. Verskillende pryse in ERP, webwerf en voedsel verhoog die foutrisiko. Stel ’n eenvoudige reël vir jou tegniese span: die geldige verkoopprys moet uit een databron in jou databasis kom; afslaginligting moet apart en datumgereguleer wees.

• price: Stuur die normale of hoofprys korrek met die regte geldeenheid.
• sale_price: Gebruik dit slegs as die afslag werklik aktief is.
• sale_price_effective_date: Stuur veldtogbegin- en einddatums.
• availability: Hou voorraadstatus saam met prys op datum.
• link: Verwys die gebruiker na die korrekte produk- of variasiebladsy.

Stap 4: Kontroleer webwerftoegang vir bots

Google moet jou produkbladsye kan lees. Maak seker dat robots.txt nie produk-URL’s, CSS- of JavaScript-bronne blokkeer nie. As pryse eers later met JavaScript gelaai word, kan Google soms ’n verkeerde prys sien of vertraag skandeer. As jou bediener stadig is, kan bots ’n ou of leë prys kry voordat die bladsy heeltemal verwerk is.

Moenie die belangrikheid van bladsyspoed en bedienerstabiliteit onderskat nie, aangesien dit Merchant Center-foute kan verminder. Alhoewel Google se skandeerstelsels in 2026 verbeter het, ervaar stadige, onbetroubare of foutiewe e-handelswebwerwe nadele by data-verifikasie. Maak seker jou produkbladsye gee 200 HTTP-status, 3xx-omleidings is kort en jou SSL-sertifikaat werk foutloos. Vir tegniese ondersteuning kan jy kyk na NVMe Hosting en Gratis SSL Installasie.

Stap 5: Werk gestruktureerde data op

Gebruik Product schema op produkbladsye om beide organiese sigbaarheid en Merchant Center-verifikasie te verbeter. Verkeerde schema is egter erger as geen schema nie. Kontroleer dat die prysveranderlike in jou tema die huidige produkprys gebruik. Vir variasieprodukte, toets of die schema-prys verander as die variasie verander.

Die prys wat in die Rich Results Test verskyn, moet dieselfde wees as wat die gebruiker sien. Die priceCurrency veld moet ’n geldige kode soos TRY, USD of EUR hê. Vir uitverkoopte produkte moet die availability veld korrek wees; om ’n ou afslagprys vir ’n uitverkope produk te wys, beïnvloed gebruikerservaring en Merchant Center-goedkeuring negatief.

Stap 6: Vra herondersoek en skandering in Merchant Center

Laai jou voedsel weer op of aktiveer die API-sinkronisering na die regstellings. Bevestig in Merchant Center dat die laaste gestuurde prys opgedateer is. Vra dan herondersoek van die problemeprodukte aan. Soms werk die outomatiese stelsel binne enkele ure, maar dit kan tot 24-72 uur neem. Maak ’n toetsgroep van produkte met klein getalle reg voordat jy groot volume korrigeer om herhaling van foute te voorkom.

Spesifieke kontroles vir verskillende platforms

WooCommerce-webwerwe

In WooCommerce kom prysfoute dikwels voor weens kas, meervoudige-geldeenheid-inproppe, dinamiese pryse of ou voedsel-inpropdata. Maak seker die gewone en afslagprysvelde in die produkredigeer-skerm is korrek. Kontroleer ook die sale price mapping-instelling in jou voedsel-inprop. As pryse op produkbladsye volgens lidmaatskap of koepon verander, stuur dan die algemene gebruikersprys in die voedsel.

As jy bedienerkas gebruik, maak seker dat kaslêers vir produkte, kategorieë en voedsel geoutomatiseer skoon gemaak word na prysveranderinge. Hier speel WordPress hosting en die regte kasinstellings ’n belangrike rol.

Shopify en gereedgemaakte e-handelsisteme

In platforms soos Shopify is prysvelde meestal netjies, maar meervoudige markte, geldeenhede en outomatiese afslag kan foute veroorsaak. Kontroleer die teikenland, geldeenheid en produkvariasie-koppeling in Google & YouTube-apps. Moet nie vergelykende pryse met verkooppryse deurmekaar maak nie. Afslag wat outomaties in die mandjie toegepas word, moet nie as voedselprys vertoon word nie, want Google aanvaar nie koepongebaseerde afslag wat nie direk op die produkbladsy vertoon word nie.

Spesiale sagteware en API-integrasies

Vir spesiale sagteware is die beste praktyk om ’n gespesialiseerde, geverifieerde en gelogde datastroom vir produkpryse te hê. Elke prysverandering moet vasgelê word met wie, wanneer, watter prys verander is en wanneer dit in die voedsel weerspieël is. As jy Content API gebruik, monitor suksesvolle antwoorde na opdaterings en registreer foutkodes sentraal. Maak ook seker dat die URL wat Google trek nie botblokkasies, landgebaseerde omleidings of sessievereistes het nie.

Permanente beste praktyke om prysinconsekwentheid te voorkom

Dit is nie genoeg om prysfoute net een keer reg te stel nie; ’n volhoubare beheermeganisme moet ingestel word. In groot katalogusse kan elke dag duisende pryse verander. Daarom moet jy eerder outomatisering, logboekhou en gereelde kontrole toepas as handmatige kontrole.

• Stel voedselopdaterings in om net na veldtogbegin- en einddatums te gebeur.
• Maak bladsy-, voedsel- en schema-kas gelyktydig skoon wanneer pryse verander.
• Kontroleer weekliks die prysversoenbaarheid van die 50 mees geklikte produkte.
• Formaliseer die BTW-ingeslote prysbeleid vir alle spanne.
• Voer prys- en URL-toetse uit vir elke variasie in variasieprodukte.
• Monitor Merchant Center se diagnoserapporte daagliks; as foutkoers bo 1% styg, doen ’n worteloorsaakanalise.
• Hou SSL, DNS, hosting en omleidings gereeld dop; ontoeganklike bladsye raak prysverifikasie.

Byvoorbeeld, in ’n winkel met 5 000 produkte waar die daaglikse prysveranderingkoers 8% is, beteken dit elke dag ongeveer 400 produkte se voedsel en bladsypryse weer getoets moet word. Dit is onprakties om alles handmatig te doen. Selfs ’n eenvoudige cron-taak wat voedselpryse met lewende URL-pryse vergelyk, kan foute vroeg opspoor.

Hoe hanteer jy versendings-, koepon- en veldtogpryse?

Versendingsfooie kan apart van produkpryse bestuur word, maar jou Merchant Center se versendingsinstellings moet korrek wees. As jy gratis versending op die produkbladsy adverteer maar by betaling ’n versendingsfooi hef, skade dit gebruikersvertroue en kan dit beleidsprobleme veroorsaak. As versendingsfooie wissel volgens land, stad, volumemaatstaf of mandjiegrootte, moet jy jou Merchant Center-versendingsreëls ooreenkomstig instel.

Wees versigtig met koeponafslag. As gebruikers ’n koepon handmatig moet invoer, moet hierdie afslag gewoonlik nie as produkprys in die voedsel gestuur word nie. As daar ’n outomatiese afslag is wat vir alle gebruikers geld, kan dit as sale_price gedefinieer word. Byvoorbeeld, as ’n produk nie 799 TRY maar 699 TRY op die produkbladsy wys, en almal kan teen dié prys koop, kan jy 699 TRY in die voedsel gebruik. Maar as die afslag net met die EFSANE10-koepon werk, kan dit prysverskille veroorsaak omdat Google ’n ander prys op die landingsbladsy sien.

Wanneer moet Google se outomatiese produkopdaterings gebruik word?

Google Merchant Center se outomatiese produkopdaterings laat Google toe om prys- en voorraadfoute tydelik reg te stel deur data van jou produkbladsye direk te lees. Hierdie funksie kan klein inkonsekwenthede verminder, maar is nie ’n permanente oplossing nie. As die data wat Google lees verkeerd is weens foutiewe schema of vertraagde JavaScript-laai, kan outomatiese opdatering ook foute produseer.

Jy kan hierdie funksie aan hê, maar dit is belangrik om jou hoofdatabron korrek te hou. Outomatiese opdaterings is ’n veiligheidsnet vir klein tydsverskille in voedselopdaterings. As die stelsel voortdurend pryse regstel, dui dit op ’n onderliggende probleem in jou voedselproses.

Die invloed van tegniese infrastruktuur op prysfoute

Merchant Center-prysfoute word dikwels in jou bemarkingspaneel sigbaar, maar die wortel van die probleem kan in jou tegniese infrastruktuur lê. Swak hostingprestasie, gereelde 500-foute, gebroke SSL, verkeerde omleidings, outomatiese geldeenheidwisseling volgens land, en aggressiewe kasinstellings kan veroorsaak dat Google pryse verkeerd lees. Dit is krities dat jou produkbladsye vinnig en stabiel reageer vir SEO, advertensiegoedkeuring en sigbaarheid in inkopie.

Hostragons bied betroubare hosting, domeinbestuur en SSL-oplossings vir e-handelsprojekte om jou tegniese basis te versterk. Byvoorbeeld, Korporatiewe Hosting help om produkbladsye beskikbaar te hou tydens hoë verkeer, terwyl Domein oordrag en DNS-bestuur omleidingsprobleme en skandeerfoute kan verminder. Die doel is nie om verkoopdruk te verhoog nie, maar om ’n betroubare data-oordrag vir Merchant Center moontlik te maak.

Kontrolelys: Laaste 12 punte voor bekendstelling

• Stem die voedsel se price veld ooreen met die produkbladsyprys?
• Word sale_price slegs tydens aktiewe veldtogte gebruik?
• Is veldtogbegin- en einddatums korrek?
• Is daar enige verpligte prysverhogings tussen produkbladsy en betaalstappe?
• Word geldeenheid in ISO-formaat gestuur?
• Maak die variasie-URL die regte variasie oop?
• Wys die Product schema die huidige prys?
• Blokkeer robots.txt Google se toegang tot die bladsy nie?
• Werk kas skoonmaak outomaties na prysveranderinge?
• Is Merchant Center se versending en belastinginstellings korrek?
• Stem mobiele en desktop-pryse ooreen?
• Is die voedsel na regstellings weer opgelaai?

Gereelde vrae

Hoe lank neem dit om ’n Google Merchant Center-prysbeleidfout reg te stel?

Na regstellings neem dit gewoonlik ’n paar uur tot 72 uur voordat produkte weer goedgekeur word. Die tydsduur hang af van die aantal produkte, skandeerfrekwensie, foutsoort en herondersoekvolumes.

Hoe moet ek afslagpryse in die voedsel stuur?

Stuur die gewone prys in die price veld en die aktiewe afslagprys in die sale_price veld. As die veldtogdatums bekend is, gebruik ook die sale_price_effective_date veld om foute te verminder.

Is dit verpligtend om BTW ingesluit te vertoon?

Ja, op Turkse e-handelswebwerwe word verwag dat pryse BTW ingesluit is. As verpligte belasting of fooie nie op die produkbladsy vertoon word nie maar eers by betaling bygevoeg word, kan dit prysverskille in Merchant Center veroorsaak.

Los outomatiese produkopdaterings prysfoute heeltemal op?

Nee. Dit kan klein tydsverskille verminder, maar sal nie ’n foutiewe voedsel of verouderde schema en prysbestuur permanent regstel nie. Die hoofdatabron moet reggestel word.

Hoe voorkom ek prysfoute by variasieprodukte?

Gebruik die korrekte prys, ’n unieke produk-ID, ’n gedeelde item_group_id en die regte landingsblad-URL vir elke variasie. Wanneer ’n gebruiker klik, moet die variasie ooreenstem met die prys in die voedsel.

Gevolgtrekking

Google Merchant Center-prysbeleidfoute ontstaan meestal uit klein verskille tussen voedsel-, produkbladsy-, schema- en betaalstapdata. ’n Permanente oplossing behels ’n enkele prysdatabron, korrekte afslagbestuur, opdatering van gestruktureerde data, vinnige en skandeerbare bladsye, en gereelde kontrole. Moet nie jou tegniese infrastruktuur ignoreer as jy wil hê jou produkte moet probleemloos in Google Shopping en gratis lyste vertoon word nie. As jy wil, kan jy Hostragons se hosting-, domein- en SSL-oplossings ondersoek om jou e-handelswebwerf se betroubare data-oordrag op ’n stewige fondament te bou.