dffggsd

Ik doelde ook niet zozeer er op, dat mijn antwoord een volledige oplossing is. Echter kan het wel een hulpmiddel zijn om in elk geval de inzet in kaart te brengen. Allicht zit ik fout, maar aan het bericht van de TS te oordelen lijkt hij te twijfelen over de inzet van zijn medewerkers?

Zelf heb ik in loondienst gewerkt bij een bedrijf als telefonisch verkoper. Wat daar goed werkte was de belminuten per medewerker bijhouden. Zo zie je precies wie de kantjes er vanaf lopen. Natuurlijk ga je dan grote verschillen zien en is dat niet meteen een indicatie van hoe goed iemand presteert.

Zo zag je soms medewerkers met ~100 belminuten per dag goed presteerden en anderen met ~150 minuten per dag minder presteerden. Echter de zichtbare lijn was wel, als medewerkers op een volle werkdag ruim onder de ~100 belminuten zaten, de prestaties altijd ook achter bleven. Medewerkers die over de 200 minuten per dag aan de telefoon zaten, presteerden altijd excellent. Het is dus wel een makkelijk te meten indicatie van de inzet.

Mijns inziens is ook goed presteren belonen een betere strategie dan slechte prestaties met 'goede gesprekken' te belonen. Daarmee riskeer je een erg onaangename bedrijfscultuur lijkt mij.

DHL heb ik persoonlijk dramatische ervaringen mee. Die is naar mijn ervaring absoluut goedkoop duurkoop. Maar dan ook niet eens daadwerkelijk goedkoop, door alle kleine lettertjes met allerlei bijkomende toeslagen. Dit houdt niet op bij brandstof toeslag, maar bijvoorbeeld ook als het pakket groter is dan meen ik 60x40x40? Ik moest in elk geval bij zeker de helft van de pakketten daar ook een toeslag voor betalen. Dat is bij PostNL en DPD nooit het geval geweest.

Het ging pas echt mis, toen ik een pakketje stuurde naar een land waar ik geen tarief afspraken voor had, namelijk Duitsland. Ik moest voor een klein pakketje van onder de 2KG 45,- Excl. BTW. betalen. Voor mij was dat echt de druppel. Ik vond dat pure oplichting en toen ik me beklag erover deed werd doodleuk gezegd 'had je maar van te voren naar de prijs moeten informeren'.

Ik heb het bij DHL 6 weken uitgehouden.

PostNL en DPD beide erg tevreden over. Ik geef mijn klanten de keuze tussen die 2. PostNL heeft als voordeel de flexibiliteit in afhaaltijden. Bijvoorbeeld 's avonds erg laat en zondag. DPD is net even goedkoper en standaard verzekerd en handtekening voor ontvangst. Kwaliteit is bij beiden vergelijkbaar. Wel moet ik zeggen dat dit jaar met de feestdagen de betrouwbaarheid bij PostNL hoger was. DPD meer klachten gehad over te late bezorging dan met PostNL. Dat is echter de rest van het jaar naar mijn ervaring juist omgekeerd. Dan heb je bij beiden erg weinig klachten, maar bij DPD dan nog net iets minder als bij PostNL.

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.

Linksignalen consolideren voor dubbele of vergelijkbare inhoud. Hierdoor kunnen zoekmachines de informatie die ze voor de afzonderlijke URL's hebben (zoals links naar de URL's), consolideren tot één voorkeurs-URL. Dit betekent dat links van andere sites naar http://example.com/dresses/cocktail?gclid=ABCD worden geconsolideerd met links naar https://www.example.com/dresses/green/greendress.html.

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.

Linksignalen consolideren voor dubbele of vergelijkbare inhoud. Hierdoor kunnen zoekmachines de informatie die ze voor de afzonderlijke URL's hebben (zoals links naar de URL's), consolideren tot één voorkeurs-URL. Dit betekent dat links van andere sites naar http://example.com/dresses/cocktail?gclid=ABCD worden geconsolideerd met links naar https://www.example.com/dresses/green/greendress.html.

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

Kijk dan even welk stukje ik van je quote - niet dat stukje met die link. Met of zonder www maakt, zoals al eerder gezegd, helemaal niks uit. Sterker nog - 301 redirects kunnen zelfs nadelig werken.

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

Hoe kom je dan van 13.000 records op 9.000 URL's?

(Bij URL-parameters zou je een tegenovergesteld effect zien: veel meer URL's dan records.)

 

Schuilt in dat verschil een logica die Google ook zou kunnen volgen om die 9.000 vervolgens tot 3.000 te reduceren?

 

Mijn eerste ingeving zou dan namelijk zijn dat veel content "meer van hetzelfde" is. Dat maakt het dan niet per se duplicate content, maar wel een massa content waarin de meer relevante pagina's het van de minder relevante gaan winnen. Bijvoorbeeld op zoekvolume of anciënniteit.

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.