dffggsd

Op zich wel een interessant idee, maar zou dit niet ook gewoon met Facebook messenger kunnen? Dan heb je wel actieve support van Facebook die je kunt gebruiken en Facebook heeft toch ook bijna iedereen? Bij Facebook krijg je ook zo'n leuk icoon bij je pagina als je snel reageert. Dat laat dan ook aan buitenstaanders zien dat je een goede klantenservice hebt. Daar heb je dan extra meerwaarde.

Dit kun je mijns inziens toch het beste een accountant voor inhuren. Heb ik destijds ook gedaan. Die heeft de voorwaarden voor de lening opgesteld en schriftelijk laten toetsen door het belastingkantoor. Schriftelijk is hier goedkeuring op gegeven. Als je het zo aanpakt, kun je ook nooit achteraf problemen krijgen met dit soort constructies. Als er een partij is waar je echt nooit problemen mee wilt, is het wel de fiscus. In Nederland wordt belastingfraude zwaarder bestraft, dan iemand zwaar mishandelen. Dus ik zou op dit vlak zeker geen risico's nemen.

Net als dat dit soort topics van Herman met een bepaalde interval steeds maar weer komen op diverse fora, kom ik ook met wederom dezelfde reactie als de laatste keer dat ik dit zag. Het probleem is iets waarvan het bespreken op zich ook naar mijn mening goed is. Echter is proberen je eigen product of dienst te verkopen via fear-marketing volgens mij niet echt een benadering die in Nederland erg succesvol is. Nederlanders zijn hier denk ik te nuchter voor en zoals te lezen in reacties van o.a. meubelmaker nuanceren ze je verhaal en gaat de strategie verloren. Fear-marketing is in de VS o.a. mega succesvol, maar ik zou het hier in Nederland toch eens op een andere manier proberen. Allicht is je product op die manier ook succesvoller te verkopen? Of als het om de stichting gaat, komt de boodschap dan bij wat meer mensen binnen? Bij mij en zoals hierboven te zien ook bij anderen, werkt deze aanpak juist averechts. Het maakt de discussie over het onderwerp, waar het over zou moeten gaan, een beetje dood.

Probleem is dus, dat niet alle structured data werkt. BreadcrumBs inderdaad wel. Dus daar blijf ik vanaf nu van af. Product en WebSite wordt voor zover ik kan zien nu helemaal niets mee gedaan door Google en Organization weet ik niet zeker. Daar is het directe effect moeilijk van te zien. Search Console geeft wel aan structured data gevonden te hebben. Product, WebSite en Organization is op ~10.000 pagina's gevonden op dit moment. Dus vandaar de vraag of iemand daar meer ervaring mee heeft. Zitten daar fouten in bij mij? Kan het zijn dat het tijd kost, voordat Google daar iets mee doet?

Dat klopt, maar die Google testing tool spoort volgens mij niet. De breadcrumps worden namelijk juist wel weergegeven in zoekresultaten. Terwijl die niet in orde zouden zijn volgens de Google testing tool. Ik heb exact hetzelfde gedaan als in hun voorbeeld. Andere testing tools, zoals die van Yandex valideren de breadcrumps ook wel. Daarentegen keurde Google de product data wel goed, terwijl daar dus duidelijk juist wel een fout in zat. Ik denk dus dat de voorlopige conclusie moet zijn, dat die testing tool van Google niet goed functioneert en dat mijn product data ook niet juist was. Dan is er alleen wel nog de vraag over, waarom mijn website AggregateRating helemaal nergens weergegeven wordt. Daar kan ik echt niets fout in ontdekken? Heeft dat gewoon tijd nodig? Zie ook: https://schema.org/BreadcrumbList Daar staat ook niets over een verplichte mainEntityOfPage. Ook de voorbeelden onderaan de pagina zit geen mainEntityOfPage in.

Even een kleine update. Heb de test tool van Yandex ook even gebruikt. Die geeft aan, dat ik bij mijn Product het brand element onterecht type 'Thing' gebruik. Dat had ik ook over genomen van het voorbeeld van Google zelf. Yandex geeft aan, dat ik enkel type 'Organization' en 'Brand' mag gebruiken. Ook aangepast. Google valideert nog steeds, Yandex nu ook. Allicht is dat waarom mijn product snippets door Google niets mee gedaan werd...?

Gedaan, maar foutmelding blijft bestaan. Heb JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT gedaan, zodat debuggen ook makkelijker wordt. Rood onderstreept is nu bij de test tool BreadcrumbList. Terwijl op schema.org dit type toch echt gewoon omschreven staat en ook in de voorbeelden van Google zelf. Het blijft dus een vreemd iets...

@peter bedankt voor de suggestie. De escapes worden door PHP gedaan. De JSON wordt gemaakt met de PHP ingebouwde json_encode. Ik zou misschien JSON_UNESCAPED_SLASHES er aan toe kunnen voegen, zou dat verschil maken denk je?

Sinds kort ben ik op mijn webshop gebruik gaan maken van schema.org structured data. Ik gebruik hiervoor LD+JSON. Nu loop ik tegen iets geks aan, waarvan ik hoop dat jullie mij kunnen adviseren. De volgende pagina wil ik als voorbeeld aanhalen: onlinedierenspeciaalzaak.com/_1-back2nature-bodembedekking-10,5-kg/ Als ik deze in de zoekresultaten zie staan, wordt de product data niet gebruikt, maar de breadcrumpslist wel. Het gekke hier aan is, dat volgens de testing tool van Google de product data correct is, maar de breadcrumsplist niet. De laatstgenoemde is exact zoals het voorbeeld op schema.org en eveneens op de structured data uitleg pagina van Google zelf. De product data is eveneens exact zoals in de documentatie van Google en schema.org te vinden is, maar wordt niet gebruikt. Daarom de vragen: Hebben jullie enig idee, waarom Google beweerd dat de breadscrumplist fout is, terwijl het een exacte kopie van hun voorbeeld is? De foutmeldingen hier zijn 'Het kenmerk itemtype heeft een ongeldige waarde.' volgens mij voor de '@id' en 'mainEntityOfPage: ontbreekt en is vereist'. Die laatste kan ik zelf wel oplossen, maar omdat de structured data nu wel correct ingelezen wordt door Google ben ik huiverig er iets in te veranderen. Weten jullie hoe het zit met product data? Kan het zijn, dat alles wel goed is, maar dat er tijd overheen gaat voor Google zoiets opneemt of dat Google in sommige gevallen kiest dit achterwege te laten? Zien jullie fouten in mijn product data? Dan tot slot, dit leek me de juiste rubriek op dit forum, maar allicht zijn er meer gespecialiseerde forums waar ik dit soort vragen beter zou kunnen stellen? Dit is mij onbekend, dus als jullie daar tips in hebben sta ik daar ook zeker voor open. _____ modedit: geen links naar eigen site, ook niet als voorbeeld!!

Wat dacht je van gewoon een retour label mee sturen als je weet, dat het sowieso retour komt? Dan kan de klant het er gewoon op plakken. Scheelt hele hoop kosten en is misschien nog makkelijker dan een antwoordnummer. De klant hoeft dan immers enkel een sticker op het pakket te plakken en niets op te schrijven. Je kunt overigens ook een stuk lagere tarieven krijgen dan wat je aangeeft via subcontractors. Als je me een PM stuurt, kan ik je wel een linkje sturen naar een erg goede partij hiervoor.

Lijkt me een pittige uitdaging. Normaal zou je dan zeggen neem een mobiel pin apparaat. Echter je bemiddeld voor vakmensen. Je kunt natuurlijk moeilijk die allemaal van een mobiel pin apparaat voorzien. Allicht eens uitpluizen of je geen incasso machtiging mee kunt werken in overleg met de bank? Dan kun je de vakmensen gewoon een voor ingevulde machtiging meegeven, die de klant dient te ondertekenen als de werkzaamheden klaar zijn. Dan heb je natuurlijk wel nog het risico op mislukte incasso's, maar je debiteuren termijn zal al snel ingekort worden lijkt mij op die manier.

@peter dat zegt de link wel. Als je er nog niet bekend mee was, ranking wordt deel bepaald door de hoeveelheid backlinks naar een pagina.

@peter Wie heeft het hier over een penalty? Ik heb het erover, dat je website beter scoort als je die aanbevelingen opvolgt. Daarbij is de domeinnaam is toch echt onderdeel van een canonical URL.

Dat zie ik toch wel als iets heel erg positiefs aan werken met voorkeursdomein, canonical URL, etc..

Daar heeft jou link helemaal niets mee te maken. Die gaat enkel over het feit, dat subdomeinen niet langer als external gerekend worden en dus ook links van website met www. naar delen zonder www. niet meer als external links tellen. In de stukken die daadwerkelijk wel over een voorkeursdomein gaan, legt Google uit hoe je een voorkeursdomein (met of zonder www) in kunt stellen en waarom dit verstandig is. Lees zelf je eigen link en mijn link even nog een keer aandachtig door. Kan allicht verhelderend voor je zijn.

Dat kan vervelend voor je zijn lijkt mij. Volgens mij zal ook de 'linkjuice' over de 'dubbele' paginas verdeelt worden. Immers is een link naar de ene, dan niet een link naar de andere en omgekeerd. Waardoor ze allebei hun eigen ranking krijgen. Als je dus kenbaar maakt, dat het eigenlijk gewoon 1 pagina is, heb je dat probleem niet. Dan hebben ze immers een gezamenlijke ranking.

@peter geen idee wat jou link met het verhaal te maken heeft. Dat is toch echt een compleet ander onderwerp. Een voorkeursdomein aangeven is toch echt wel wat Google aanbeveelt. Heb je mijn link überhaupt bekeken?

Als het om je ranking gaat, zou ik meer proberen uit te sluiten dat content via verschillende wegen bereikbaar lijkt. Nogmaals, je geeft aan, dat uit je sitemap 3000 geïndexeerd zijn, maar indexering status geeft aan dat er 9000 pagina's geïndexeerd staan? Google indexeert dubbele content gewoon. Echter laat Google in de resultaten dan vrijwel altijd slechts 1 zien. Zelf zie ik dat in mijn search console heel duidelijk terug. Daarom zou ik je dus echt met klem willen adviseren voor elke pagina een rel="canonical" toe te voegen met de URL, zoals deze in de sitemap staat. Dan sluit je dat 100% uit. Dat is een aanbeveling van Google zelf. Tips om content dubbel indexeren te voorkomen van Google zelf: https://support.google.com/webmasters/answer/139066?hl=nl

Simpel, wat hij al aangeeft er zijn 3000 uit sitemap geïndexeerd. Als alle pagina's via www. en zonder www. geïndexeerd zouden staan, zit je al op 6000. Pak je ook nog https:// en http:// erbij, verdubbelt het naar 12000. Zelfde idee voor URL parameters. Dat is natuurlijk te zwart wit, omdat de kans klein is, dat alle varianten een zelfde crawl rate etc hebben. Dat zal niet zo zijn. Vandaar dat het dan niet vreemd is. Je hebt dan dus, dat pagina's die je niet wilt wel geïndexeerd zijn en pagina's die je wilt niet geïndexeerd zijn. Dan is er daarbij inderdaad ook allicht een deel oude content wat nog geïndexeerd staat? Lijkt me echter wel wat veel, als dat 6000 pagina's zijn? Je zou daarvoor nog kunnen nakijken dat je website geen soft 404's genereert. Als een pagina er niet meer is, dient daar of een 301 of een 404 te komen. Geen 'soft 404'. Je kunt een hoop van deze oorzaken uitsluiten door www. en zonder www. 1 van beiden van te kiezen en de een naar de ander te 301 redirecten en https en http hetzelfde mee doen. Als je dan ook nog je URL parameters controleert en tot slot nog even nakijkt of je in de metatag een rel="canonical" gebruikt. Door dat te doen ga je als het goed is dan pagina's die via verschillende URL's toegankelijk zijn met elkaar fuseren. Dat zou ten goede moeten komen aan de ranking. Heb ik zelf vorige week ook gedaan. Bij mij is het beeld nog vreemder. Ik hoop, dat dit langzaam maar zeker opgelost is hiermee. Bij mij is het nu: sitemap: 57.921 URL's verzonden 36.847 URL's geïndexeerd indexeringsstatus: Totaal geïndexeerd 333.589

Allicht heb je URL parameters die zorgen voor ogenschijnlijk dubbele content. Dat dus eenzelfde pagina 2 of 3 keer voorkomt, maar dan met een URL parameter. Die kun je ook uitschakelen, als dat het geval is. In Search Console van Google kun je URL parameters opgeven die Google dient te negeren. Allicht richt dat iets uit? Dan heb je nog de mogelijkheid, dat je content aan de gebruiker biedt via www. en zonder www.. Het is aan te bevelen 1 van beide te kiezen en de rest 301 te redirecten. Zelfde is van toepassing voor http:// en https:// Je sitemap stuurt waarschijnlijk dan wel slechts 1 in, maar de content staat op meerdere. Daardoor heb je dan dat niet de hele sitemap geïndexeerd is, maar wel pagina's geïndexeerd staan, die niet in de sitemap voorkomen. Ik hoop dat deze suggesties je helpen. Ben benieuwd of ik goed gok met deze mogelijkheden. Verder zou ik ook zo niets kunnen bedenken.

Na alles gelezen te hebben, heb ik ook het idee dat het verhaal wel wat rammelt. Eerst zouden er aanpassingen gedaan zijn wegens warmte, terwijl de taart in Maart geleverd is? Daarna is het weer de luchtvochtigheid? Of heb ik het compleet verkeerd begrepen? Persoonlijk denk ik, dat als iemand na anderhalf jaar hier een jurist voor ingeschakeld heeft, er wel meer speelt. Dan zit het blijkbaar erg hoog. Allicht oordeel ik nu wat hard, maar ik heb het idee dat TS het een en ander verzwijgt of afwijkt van de waarheid. Op dit forum zitten duidelijk ervaren juristen. Ik wil TS adviseren zo oprecht mogelijk te zijn, ook over de eigen fouten. Dat zorgt ook voor een zo nuttig mogelijk advies. Dan tot slot een vraag aan de juristen hier. Is zo'n claim bij een dergelijk product niet gewoon na meer dan een jaar sowieso verjaard? Als er echt meer dan een jaar na een schikkingsvoorstel niet tussentijds gereageerd is en vervolgens een brief van een jurist komt, is zoiets toch gewoon sowieso verjaard? Ik weet ook niet of verjaard de juiste term hier in is?

@peter Fijn dat je nu in elk geval wel erkend, dat de URL dus wel invloed heeft, ook al is de hoeveelheid invloed onduidelijk. De wijzigingen merk ik overigens vooral nu al terug in dat ik blijkbaar zoekmachines wakker geschud heb. De hoeveelheid traffic van robots is de laatste 2 dagen gigantisch toegenomen en is zelfs merkbaar in server performance. De webserver is in zijn geheel sinds 2 dagen 10-15% trager hierdoor... website draait op VPS.

En over canonical URL in je HTML header gebruiken.. Dat is niet enkel aangeven wat je graag in de zoekresultaten wilt hebben staan. Daar kun je beter structured data voor gebruiken. Het is meer om content te ontdubbelen. Je geeft daarmee eigenlijk aan, dat die ogenschijnlijk verschillende pagina's er eigenlijk 1 zijn. Daarmee voeg je de pagerank samen en voorkom je duplicate content penalty.

@peter wow, jij bent volhardend in je opvattingen. Op kattenbak staat Pet's Place bij mij op nummer 6 en hebben de overige 9 allemaal het woordje kattenbak in de URL. Pet's Place is een domein met een bijzonder hoge waarde. In combinatie met de content, is dit daarom 1 van de uitzonderingen. Vandaar, dat ik zei 'zelden' en niet 'nooit'. Als je serieus denkt dat Google niet naar de URL kijkt. Dan heb jij in elk geval een revolutionair standpunt, waar zelfs Matt Cutts zelf eerder van aangegeven heeft, dat het niet zo is. Ik ga dan toch echt op wat ik zie in de zoekresultaten af in combinatie met wat logisch lijkt en wat Matt Cutts zelf zegt.

Sowieso natuurlijk is het belang van Google om zo relevant mogelijke resultaten aan de gebruiker te tonen. Echter worden die resultaten niet door mensen gegenereerd, maar door een algoritme. Een complex algoritme, maar nog geen AI. Google vraagt daarom ook letterlijk om hulp van webmasters om beter te bepalen waar een pagina precies over gaat. Zo kunnen zij op hun beurt de gebruikers weer beter relevante informatie bieden. Mijns inziens zou het zelfs heel stom zijn, als de URL niet in het algoritme meegewogen wordt. Als iemand 'fietsbel' zoekt is de kans immers groter relevante content te vinden in bestand fietsbel.html als in deurknop.html. In de praktijk zie je dit ook in de zoekresultaten terug. Zelden zie je op de eerste pagina resultaten waarbij het zoekwoord niet in de URL voorkomt. Enkel content voor de gebruiker is aantoonbaar complete onzin. Neem nou bijvoorbeeld zoals eerder genoemd de HTTP headers. De gebruiker ziet die niet. De robot wel. Sinds kort moedigt Google webmasters zelfs aan om onzichtbare content voor robots toe te voegen in de vorm van structured data in LD+JSON formaat. Daardoor is het op 1 lijn trekken van wat een zoekmachine boeit en wat een gebruiker boeit een fout. Dan heb je nog zoiets als canonical URL's via een HTML header aangeven. Dat voegt voor de gebruiker niets toe, die ziet dit niet, maar wederom wel voor de robot. Kortom, in de basis ben ik het met je eens Peter. Google zal altijd trachten gewoon zo relevant mogelijke resultaten te tonen. Daarom weegt content altijd erg zwaar. Echter lijkt het, alsof je daarbij vergeet dat een algoritme wat bepaald wat relevant is, nooit perfect is. Weten hoe je zo'n algoritme zo goed mogelijk duidelijk kan maken waar je pagina over gaat is in feite wat SEO onderaan de streep is. Google is daar schimmig over om misbruik te voorkomen, maar geeft wel bepaalde hele duidelijke handvatten in hun eigen documentatie. Omschrijvende Title tags en URL's horen daar toch echt wel bij. Concreet voorbeeld: https://www.onlinedierenspeciaalzaak.com/_1-mp-kattenbak-flip-cat-donkerblauw-50,5x38,5x38-cm/ Daar komt het woordje 'online' net zo vaak voor als 'kattenbak'. Het woordje 'dierenwinkel' is zelfs 2% keyword density. Als het puur om content gaat. Hoe moet een algoritme dan snappen dat deze pagina over kattenbakken gaat als er zoveel andere woorden zoveel voorkomen? Dan moet je dus als webmaster dat op andere manieren vertellen. Bijvoorbeeld de Title tag, de URL, anchor text naar de pagina toe, kopteksten, structured data, etc..