Paginering / dubbele content / Google index?

GrutekeGruteke Member Berichten: 21
Ik zie in de google resultaten urls van categoriepagina's terugkomen die niet bestaan. bijv. https://www.domeinnaam/categorie/page12.html. Het getal 12 is te vervangen door elke willekeurig getal, en de pagina is aangemaakt in Lightspeed en verwijst naar de originele categoriepagina.

Bovendien komen sommige terug in de zoekresultaten met als gevolg dubbele content omdat er wordt verwezen naar de originele categoriepagina. Ik heb het idee dat dit al een tijdje gaande is, vanaf juli?

Hebben andere Lightspeedshops hier ook last van? En wat zijn de gevolgen voor indexering in Google met al die dubbele content?


Ben benieuwd.


<1

44 reacties

  • RosaRosa Member Berichten: 30
    Hi @Gruteke,

    Ik weet het niet precies, maar volg dit onderwerp wel even met je mee :-)
    Zijn het misschien de collectie pagina's? En misschien is er een cannonical ingesteld?
  • GrutekeGruteke Member Berichten: 21
    @Rosa. Misschien heeft @Lightspeed Team een antwoord hierop?
  • GrutekeGruteke Member Berichten: 21
    @Sven Udo Dat is handig dat vreemden je er op wijzen :| . Wij zijn dus blijkbaar niet de enige. Ik hoop dat @Lightspeed Team misschien ook kan reageren.
  • StefanStefan Member, Partner Berichten: 31 partner
    oktober 2018 aangepast
    Hi allen, 

    Om te voorkomen dat .page2, page3 etc. pagina's worden geïndexeerd / gecrawld kan je het volgende toevoegen aan je robot.txt bestand.

    Disallow: *page2*
    Disallow: *page3*
    Disallow: *page4*
    Disallow: *page5*
    Disallow: *page6*
    Disallow: *page7*
    Disallow: *page8*
    Disallow: *page9*
    Disallow: *page10*
    Disallow: *page11*
    Disallow: *page12*
    Disallow: *page13*
    Disallow: *page14*
    Disallow: *page15*
    Disallow: *page16*
    Disallow: *page17*
    Disallow: *page18*
    Disallow: *page19*
    Disallow: *page20*

    Enzovoorts natuurlijk! ;-) 
    Met vriendelijke groet,

    Stefan Molders

    Molders Media

    Molders Media B.V.
    Telefoon: + 31 (0) 85 - 060 15 70
    E-mail: [email protected]
    Website: https://moldersmedia.nl/
  • GrutekeGruteke Member Berichten: 21
    @Stefan. Verlies je hiermee ook niet de links naar de producten vanaf de categoriepagina?

  • StefanStefan Member, Partner Berichten: 31 partner
    @Sven Udo

    Wanneer je aan je robot.txt het volgende toevoegt worden filters, sorteringen en al het andere met parameters ook niet meer gecrawld: 

    Disallow: *?*
    Met vriendelijke groet,

    Stefan Molders

    Molders Media

    Molders Media B.V.
    Telefoon: + 31 (0) 85 - 060 15 70
    E-mail: [email protected]
    Website: https://moldersmedia.nl/
  • StefanStefan Member, Partner Berichten: 31 partner
    oktober 2018 aangepast
    @Gruteke

    Nee, dit kan geen kwaad! ;-) 

    Dit passen wij standaard toe bij de webshops die bij ons de dienst zoekmachine optimalisatie afnemen en hebben er nog nooit problemen mee gehad. 
    Met vriendelijke groet,

    Stefan Molders

    Molders Media

    Molders Media B.V.
    Telefoon: + 31 (0) 85 - 060 15 70
    E-mail: [email protected]
    Website: https://moldersmedia.nl/
  • RosaRosa Member Berichten: 30
    @Sven Udo
    Denk dat je deze zelf al had bedacht hoor (C) Homepage heeft geen H1 ), maar header homepage kan je zelf natuurlijk goed zetten bij inhoud>pagina's

    En uhm.... weet iemand hoe je kunt zien hoeveel pagina's je dan kunt hebben? Rijtje van Stefan loopt tot 20 als voorbeeld, maar hoe kan ik dat bij mijn shop zien? Gewoon de grootste categorie uitzoeken in je shop?

  • StefanStefan Member, Partner Berichten: 31 partner
    @Rosa

    Yes, even kijken welke categorie het grootst is en tot dat nummer aanmaken.
    Met vriendelijke groet,

    Stefan Molders

    Molders Media

    Molders Media B.V.
    Telefoon: + 31 (0) 85 - 060 15 70
    E-mail: [email protected]
    Website: https://moldersmedia.nl/
  • RosaRosa Member Berichten: 30
    @Stefan
    top, thanks!!
  • FrankFrank Member Berichten: 126 ✭
    Stefan bedankt.
    Meteen even in het robot.txt bestand gezet.
    En weer iets nieuws geleerd vandaag.
  • SoniaSonia Member Berichten: 125 ✭
    Moet je dit ook inzetten om te voorkomen dat accountpagina's en wishlists worden geïndexeerd? Die komen bij mij ook naar boven.

  • GrutekeGruteke Member Berichten: 21
    Is dit het probleem misschien? @Lightspeed ???

    Pagina 2 refereert aan pagina 1 als rel=prev, wat zorgt voor dubbele indexatie en kannibalisatie doordat pag=1 identiek is aan de oorspronkelijke pagina zonder de parameters.

    Deze bug zorgt er dus voor alle categoriepagina's dubbel ingeladen (meerdere keren) waardoor de categoriepagina's langzaam dalen door de grote hoeveelheid dubbele content
  • citizen_zoocitizen_zoo Member Berichten: 88 ✭
    @Gruteke dat is het probleem.

    rel=prev op page2.html verwijst niet naar de root maar naar een niet intern gelinkte page1.html en breekt daarmee de sequentie. Al ruim een jaar bekend bij Lightspeed dat rel= prev op page2.html aangepast moet worden. Meer niet!
    Hier kun je het zelf testen:

    https://technicalseo.com/seo-tools/rel-prev-next/

    Of gebruik Screaming Frog, DeepCrawl, SiteBulb of Content King (https://www.contentkingapp.com/academy/pagination/ om de pagination te testen.



    je ziet 64x dezelfde pagina geïndexeerd. Dit is funest en wordt door Google afgestraft.

    O ja? Om je kapot voor te schamen. Wat is dit voor een argument?  Googlebot "ziet" niet 64x "dezelfde" pagina... Hoe kom je erbij? Elke pagina heeft een eigen url met unieke content.

    Je maakt je zorgen over duplicate titles en descriptions errors in Google Search Console? Al lang bekend en bevestigd in de SEO community en door Google dat dat normaal is!





    Wat de developers van Lightspeed afgelopen week gedaan hebben met de canonical naar de 1ste pagina, dat is funest! Ik kan dit niet waarderen.


    2013!

    Meer documentatie:
    https://yoast.com/pagination-seo-best-practices/

    Google is very clear now: each page within a paginated series should canonicalize to itself, so /page/2/ has a canonical pointing to /page/2/.

    https://www.contentkingapp.com/academy/pagination/

    If you're a webmaster, SEO or business owner, you've probably had to deal with pagination at some point. Whilst paginations aren't difficult, they can be daunting if you're not sure how or when to use them. The most common mistake I see is the rel="canonical"directive on paginated results pointing back to page 1. This outdated tactic has been implemented in the past by users attempting to flow link equity to that URL. Despite Google confirming that this tactic isn't recommended, it remains a common mistake. Don't trick Google into believing you only have a single page of results, and make sure you use canonicals and paginations correctly.

    https://www.gsqi.com/marketing-blog/how-to-set-up-pagination-rel-next-prev/

    Warning: Don’t Canonicalize All Component Pages To The First Page! Set Up Rel Canonical Correctly
    Also, and this is important to understand, if you canonicalize all component pages to the first page in your pagination, then Google can’t index any of the additional content. So you are diminishing the power of the paginated set by canonicalizing each component page to the first page. It’s simply not the right setup.


    @MoldersMedia robots.txt is voor het controleren van de crawl. Niet geschikt om te voorkomen dat pagina's in de index komen. Het kan zeker kwaad; Door filters te blokkeren verlies je ook de linkwaarde. Want Googlebot "ziet" deze links niet.
  • GrutekeGruteke Member Berichten: 21
    Eindelijk iemand die het snapt. Nu Lightspeed nog.
  • GrutekeGruteke Member Berichten: 21
    @citizen_zoo Is dit van toepassing op alle lightspeed shops met categorieën van 25 producten?
  • StefanStefan Member, Partner Berichten: 31 partner
    oktober 2018 aangepast
    @citizen_zoo

    Klopt inderdaad dat de rel=prev op pagina 2 doorverwijst naar pagina 1. Dit is ook al vaker doorgespeeld maar nog steeds niet veranderd.... Tevens zou alleen de rel=prev en rel=next voldoende moeten zijn om problemen zoals duplicate content tegen te gaan en de link waarde toe te schrijven aan de categorie zelf i.p.v. de paginering.

    Omtrent je punt over de robot.txt: daar is het wel degelijk geschikt voor alleen is er geen garantie dat de pagina's die je opneemt in het robot.txt bestand ook niet geïndexeerd worden. Met de robot.txt voorkom je alleen het probleem omtrent duplicate content.

    Voor de filters is het zeker wel aan te raden om dit op te nemen in je robot.txt bestand: 

    1. Filters zijn ook bereikbaar voor Google maar bevatten geen toegevoegde content. Filters zijn vaak als het ware lage kwaliteit links. 
    2. Gebruikt veel crawl budget

    Dit zijn de meeste gebruikte pagina's in een robot.txt bestand voor webshops: 

    • Winkelwagen
    • Account pagina's 
    • Filters
    • Sorteringen
    • Paginering (zie hieronder voor meer uitleg)

    Wat ik al aangaf zojuist zou enkel de rel=prev en rel=next de problemen moeten tackelen. Helaas in de praktijk zie je dat dit vaak niet gebeurd waardoor de oplossing met de robot.txt aan te pas komt. Verder is er nog de oplossing meta tag robots, met codewerk op te lossen en niet via de instellingen dus dan is de robot.txt het makkelijkst om toe te passen. 
    Post edited by Stefan on
    Met vriendelijke groet,

    Stefan Molders

    Molders Media

    Molders Media B.V.
    Telefoon: + 31 (0) 85 - 060 15 70
    E-mail: [email protected]
    Website: https://moldersmedia.nl/
  • StefanStefan Member, Partner Berichten: 31 partner
    @citizen_zoo

    De canonical is inderdaad aangepast door Lightspeed. Deze staat in het bestand head.rain. Oplossing hiervoor: een custom head.rain zodat je dit alles zelf kan aanpassen. 

    Enige nadeel is dat mocht je sommige apps installeren moet je het script daarvan zelf toevoegen aangezien dit afgesloten pagina's zijn van Lightspeed evenals de body.rain (hier zitten de meeste geïnstalleerde apps in). Dit geldt ook met de meta-tag verificatie bij de instellingen. Het zou een oplossing kunnen zijn wil je alles zelf in de hand hebben / houden. 

    is trouwens ook direct het issue van de page1.html getackeld met de rel=prev. 
    Met vriendelijke groet,

    Stefan Molders

    Molders Media

    Molders Media B.V.
    Telefoon: + 31 (0) 85 - 060 15 70
    E-mail: [email protected]
    Website: https://moldersmedia.nl/
  • citizen_zoocitizen_zoo Member Berichten: 88 ✭

    @Gruteke Bij alle shops is het van toepassing

     Als je de volgende parameter ?limit=1 toevoegt aan de url van een categorie/brand of een andere overzichtspagina kun je dat goed zien.

    De paginering hangt af van het aantal producten en de limiet die is ingesteld: in alle thema's is dit dynamisch.

    Hoe lager de limiet, hoe meer pagina's.
    Hoe hoger de limiet, hoe minder pagina's. 

    Het aantal producten op een pagina.
    • In de backend kan bij design de standaard limiet worden ingesteld.
    • Sommige thema's tonen die keuze ook aan de voorkant als sorteeroptie aan de bezoeker. 
    • In bepaalde thema's zit ook een infinite scroll/view all optie verwerkt. Zo'n setup heeft weer andere nadelen, o.a. laadtijd. 

    Voorbeeld view all / infinite scroll:

    https://www.mevrouwaardbei.nl/nl/posters/

    https://www.mevrouwaardbei.nl/nl/posters/?limit=6

    Bij het scrollen laadt de pagina door de hierboven ingestelde limiet steeds 6 producten, tot het maximum is bereikt. 

  • SharmanySharmany Member Berichten: 37
    @Stefan Vraagje hierover: als je er een disallow op zet dan blijven de gepagineerde pagina's die op het moment van instellen al geindexeerd zijn toch "zweven"? Ze zijn geindexeerd en daarna zeg je tegen Google dat ze de pagina niet meer mogen benaderen.
    www.boozyshop.nl
    Dé Make up webshop van Nederland!
  • StefanStefan Member, Partner Berichten: 31 partner
    @Sharmany

    Klopt wat je zegt maar als de page pagina's altijd onder de indexering staan van de echte categorie URL is er geen probleem en kan het alleen maar beter zijn (er is ineens nog maar 1 pagina met unieke content i.p.v. meerdere en dat is beter natuurlijk)! ;-) 

    Ik zie zelf inderdaad wel eens dat page pagina's geïndexeerd worden alleen ik heb nog niet vaak (wel is) gezien dat een page URL hoger staat dan de categorie URL zelf. Bedoeling is dan dat je met de robot.txt ervoor wilt zorgen dat de page URL niet meer voorkomt in de resultaten. 

    Als je wilt kan ik wel eens een scan maken voor je met welke page pagina's er geïndexeerd worden in Google. Mail dan even naar [email protected] Kost je helemaal niks! ;-) 

    Fijn weekend. 
    Met vriendelijke groet,

    Stefan Molders

    Molders Media

    Molders Media B.V.
    Telefoon: + 31 (0) 85 - 060 15 70
    E-mail: [email protected]
    Website: https://moldersmedia.nl/
  • GrutekeGruteke Member Berichten: 21
    @stefan en @citizen_zoo Ik heb van LS begrepen dat ze het verhaal van de canonical niet gaan aanpassen, het is geen issue. 

    rel=prev en rel=next wordt wel aangepakt, wanneer weet ik niet. Wellicht kan @Lightspeed hierop reageren? 


    Ik ben eigenlijk op zoek naar een duurzame oplossing van het bovenstaande probleem. Wie heeft er een suggestie die SEO proof is?

    We hebben nu de robots ingezet maar dat is ook niet optimaal.
  • citizen_zoocitizen_zoo Member Berichten: 88 ✭

    Klopt niet: het is wel een issue. Het kan mij niet schelen dat page*.html in de zoekresultaten staat, dat is juist de bedoeling. Ik rank die pagina's. 

    De vraag is wanneer gaan ze rel=prev rel=next eindelijk aanpakken? En de canonical weer zelfverwijzend maken.

    ~ Die canonical naar de root slaat helemaal nergens op... Hoe komen ze daarbij? Lightspeed loopt lichtjaren achter. 

    ~ Crawl van gepagineerde pagina's blokkeren in robots.txt is geen oplossing. Is niet SEO-proof, zullen we maar zeggen. Gepagineerde pagina's hebben niks te maken met duplicate content. Dat is een misverstand. Doe dat niet. De bovenstaande links bijvoorbeeld tellen niet, als je dat doet. Nofollow, ik weet het, maar het gaat om het principe. Ik kan meer dan genoeg waardevolle links aantonen die geen pagerank doorgeven, omdat robots.txt dat niet toestaat. 

    URL Parameters configureren in Google Search Console (oude versie) en eventueel in Bing Webmaster Tools (is veel beter. Haal er wel een  technische SEO expert bij. 

    Documentatie:

    https://yoast.com/wordpress-robots-txt-example/

    Robots.txt denies links their value

    There’s something else that’s very important to remember: if you use your site’s robots.txt to block a URL, search engines won’t crawl it. This also means that they can’t distribute the link value pointing at blocked URLs. So if there’s an area of your site that has a lot of links pointing at it but you’d rather not have appear in search results, don’t block it via robots.txt, use a robots meta tag with a value of noindex, follow instead. This allows search engines to properly distribute the link value for those pages across your site.

    https://yoast.com/ultimate-guide-robots-txt/

    Con: not removing a page from search results

    Even though you can use the robots.txt file to tell a spider where it can’t go on your site, you can’t use it tell a search engine which URLs not to show in the search results – in other words, blocking it won’t stop it from being indexed. If the search engine finds enough links to that URL, it will include it, it will just not know what’s on that page. 

    If you want to reliably block a page from showing up in the search results, you need to use a meta robots noindex tag. That means that, in order to find the noindex tag, the search engine has to be able to access that page, so don’t block it with robots.txt.

    Con: not spreading link value

    If a search engine can’t crawl a page, it can’t spread the link value across the links on that page, but if it can crawl, but not index the page, it can. When a page is blocked with robots.txt, any link value is lost.

    https://www.contentkingapp.com/academy/crawler-traps/

    Advice:

    Avoid using query parameters in URLs as much as possible. But if you do need to use them, or deal with them in general, then make sure they aren’t accessible to search engines, by excluding them using the robots.txt file or by setting up URL parameter handling in Google Search Console and Bing Webmaster Tools.

    The exception here is if you have query parameters in URLs that have lots of links. In order to allow search engines to consolidate signals through canonical URLs to the canonical version of these URLs, they need to be crawlable. In that case, don't disallow these URLs using robots.txt file.

  • GrutekeGruteke Member Berichten: 21
    @citizen_zoo dat is een duidelijk verhaal.Hopelijk snapt development van Lightspeed het nu. Lightspeed mag ook reageren op deze post  ;)
  • fraaibuitenfraaibuiten Member Berichten: 15
    Denk je nou echt dat lightspeed hier iets aan gaat doen? 
  • MichelleMichelle Member Berichten: 7
    Hallo,

    Ik ben benaderd door een organisatie (Traffictoday) die aangeeft dat er een bug op mijn Lightspeed site zit en dit een kritiek punt is, omdat je hierdoor in Google gaat zakken (en blijft zakken als een oplossing uitblijft). Waarschijnlijk hebben veel meer webshops hier last van en daarom wil ik hun reactie en de reactie van Lightspeed graag met jullie delen.

    First things first: het gaat om duplicate content.

    Hieronder volgt de uitleg over de bug die zij gevonden hebben:

    1. Canonical op losse pagina's is niet zelfverwijzend, maar gaat naar de base-url van de categorie.
    2. Op pagina 2 van een categorie, wordt in de code page1.html als rel="prev" aangegeven, dit zou eigenlijk de base url moeten zijn van een categorie, dus:

    rel="prev" href="https://www.voorbeeld.nl/categorie/"
    in plaats van:
    rel="prev" href="https://www.voorbeeld.nl/categorie/page1.html"/

    3. Momenteel zijn alle pagina's buiten de pagineringsset bereikbaar, dus stel je hebt 3 pagina's, pagina 50 en 82 zijn bijvoorbeeld ook benaderbaar.

    Het zorgt ervoor dat de volgende URL's hetzelfde zijn en ook dubbel geïndexeerd worden.

    rel="prev" href="https://www.voorbeeld.nl/categorie/"
    zelfde als
    rel="prev" href="https://www.voorbeeld.nl/categorie/page1.html"/

    Ze zijn allebei bereikbaar en identiek.

    Ik heb n.a.v. deze feedback contact opgenomen met Lightspeed en op 31 oktober onderstaande reactie ontvangen:

    We hebben al even naar de melding gekeken. Op het moment hebben wij direct contact met Traffictoday mbt de de canonical URL.
    De melding is namelijk ontstaan doordat wij juist dit hebben aangepast op basis van de feedback dat een zelf verwijzende canonical URL duplicate content meldingen veroorzaakt. 

    Op dit moment zijn we aan het wachten op de documentatie die traffic today gaat aanleveren om zo een conclusie te trekken over welke optie het meest opleverd.

    ---

    Op 5 november ontvang ik een reactie van Traffictoday:

    "Wat betreft de Lightspeed issues hier zijn we ook mee in gesprek en de ontwikkelaars zouden deze week de oplossing bespreken en aangeven op welke termijn dit wordt doorgevoerd en of het wordt doorgevoerd. Ik kan dus niet exact inschatten hoe lang dit gaat duren."

    ---

    Daarna blijft het akelig stil. Voor mij is het probleem dus helaas nog steeds niet opgelost. Ik zie in Search Console bij HTML-verbeteringen dat er veel pagina's dubbele beschrijvingen in de meta-tags hebben en dubbele title-tags. Dit kan toch nooit goed zijn voor je website? 

    Traffictoday heeft als oplossing voorgesteld om een infinite scroll te bouwen. Dit is een tijdelijke oplossing, want het probleem kan alleen door Lightspeed opgelost worden.

    Zien jullie ook een daling op 27 september in organisch traffic? En kan het één met het ander te maken hebben? Ik weet namelijk dat er op 27 september een Google algoritme update heeft plaatsgevonden, maar is er inmiddels al bekend wat de reden kan zijn waarom een shop getroffen is door deze update? Heeft dit bijvoorbeeld met duplicate content te maken (zie bug hierboven), ligt het probleem ergens anders of is het een combinatie van meerdere factoren (en zo ja, welke?)?

  • JohanJJohanJ Member Berichten: 231 
    Bij ons geen daling op 27 september. Op 29 september een miniscuul dipje maar meteen daarna weer een (grotere) stijging.
  • citizen_zoocitizen_zoo Member Berichten: 88 ✭
    First things first: het gaat niet om duplicate content.

    Second: meldingen voor dubbele beschrijvingen en titels voor gepagineerde pagina's in Search Console kun je negeren. 



    Third: View All met een canonical naar de root is alleen een optie als er een View All pagina bestaat. 

    4th: Don't block in robots.txt
     


    Documentatie:


  • Alex LeistraAlex Leistra Member Berichten: 86 ✭
    Ik zie zojuist een bugfix in de changelog:

    "We hebben de tag voor gepagineerde inhoud verbeterd, deze pagina's verwijzen nu beter naar elkaar. Dit zal je helpen met de SEO!"

    Met deze tekst weten we uiteraard niet wat ze veranderd hebben maar daar zal wel uitleg over komen?

  • PaulaPaula Member, Beta tester Berichten: 1,246 
    Ik snapte hem ook al niet, maar ik dacht ik zal wel de enige zijn  :D
    www.devrolijkeengel.nl
    "voor Hemelse geschenken met een vleugje Mysterie"
Log In of Registreer om te reageren.