Welke HTTP-status is het meest geschikt voor "out of bound"

[Firesphere]

Ik heb een pagina, met zo'n 3000 records, paginering toepassen lijkt me dan wenselijk.

Alleen, wat als (vooral bots doen dit) de bezoeker de start=4000 bezoeken. Dan krijgt hij een lege pagina.
Een hele hoop lege pagina's.

Nu redirect ik alles naar de hoogst mogelijke pagina (start=3000) met httpstatus 400.

Maar is die HTTP-status wel de beste? Zo niet, welke is beter?

Het is sowieso niet een 404 of 301/302, want in de toekomst kan het best zijn dat er 4000+ records zijn, en dan moet de start=4000 gewoon het juiste resultaat geven.

Ik denk aan 305 of 307, maar ben niet zeker of dat een permanent geeft, en dus de hogere waardes voorgoed blokkeerd voor zoekmachines.

[ Voor 11% gewijzigd door Firesphere op 30-01-2014 18:47 ]

[djluc]

404 vind ik nog niet zo gek eigenlijk, het is er toch niet?

[Firesphere]

djluc schreef op donderdag 30 januari 2014 @ 18:52:
404 vind ik nog niet zo gek eigenlijk, het is er toch niet?

Probleem met 404 is dat het door Google als "permanent" wordt gezien, en de bot de pagina ook voorlopig niet meer zal bezoeken.
Met i=4000 is dat niet zo'n probleem natuurlijk, maar 3001 zou zomaar morgen wel een valid resultaat kunnen geven.

[OnTracK]

404 wordt niet door Google gezien als definitief. Daarvoor hebben ze special genoemd dat je 410 moet gebruiken. Dat een crawler er niet direct komt als de pagina plotseling wel bestaat is zo, maar Google heeft vrij snel door als dat soort dingen veranderen hoor.

[Firesphere]

Maar aan de andere kant, is het technisch gezien geen 404. Het is een 200 met de volledige lay-out, werkend, maar geen content omdat de ArrayList leeg is.
Daarom dacht ik aan een 307 of 305, "Kijk hier maar voor passende content".

Weet je trouwens zeker dat 404 niet als definitief wordt gezien? Lang geleden dat ik in http-statusses ben gedoken. 301 etc. ken ik wel, maar deze lijkt me niet echt 404 of 400, maar ook 307 of 305 zijn het "net niet".

Ik vind het wel apart dat er geen "out of bound" error bestaat, wat dat betreft. Want als ik de statuscodes bekijk is er niet een die precies dat zegt, namelijk "Je probeert een te hoge paginering, dit is de maximale waarde momenteel beschikbaar"

[Fish]

416 Requested Range Not Satisfiable
The client has asked for a portion of the file, but the server cannot supply that portion.[2] For example, if the client asked for a part of the file that lies beyond the end of the file.[2]

?

[Sebazzz]

In iedere geval ergens in de 4xx range (het is immers een client fout).

[Miyamoto]

Firesphere schreef op donderdag 30 januari 2014 @ 19:22:
Maar aan de andere kant, is het technisch gezien geen 404. Het is een 200 met de volledige lay-out, werkend, maar geen content omdat de ArrayList leeg is.

http://www.google.nl/notfound
http://tweakers.net/404

Volledig met "content". Het is gewoon een 404.

[Firesphere]

Zoals ik zei, lijken een paar 3xx ook wel geschikt, maar 416 lijkt me inderdaad ook een goede. Out of bound, buiten bereik, portion niet beschikbaar.

Miyamoto schreef op donderdag 30 januari 2014 @ 19:29:
[...]


http://www.google.nl/notfound
http://tweakers.net/404

Volledig met "content". Het is gewoon een 404.

Dat is een specifieke 404 pagina, terwijl in mijn geval, de juiste pagina gewoon verschijnt (als ik de redirect uit zet), met de juiste content van die pagina, maar zonder de bijbehorende paginated items vanaf start=4xxx
Oftewel, het is een out-of-bound, niet een not-found.

Hoe zit dat trouwens met get requests. Als ik op ?start=4000 een 404 geef, wordt dan niet de hele root als 404 gezien?

Sebazzz schreef op donderdag 30 januari 2014 @ 19:27:
In iedere geval ergens in de 4xx range (het is immers een client fout).

Is dat wel zo? Hoewel mijn paginerings-linkjes niet boven de 3010 komt momenteel, is het natuurlijk ook een beetje een programmers-error dat er hogere waardes opgeroepen kunnen worden.

[ Voor 19% gewijzigd door Firesphere op 30-01-2014 19:34 ]

[Sebazzz]

Tweakers en Bing negeren de te hoge parameter, geven HTTP 200 OK terug, en returnen dan respectievelijk de eerste pagina en laatste pagina

[Firesphere]

Heb ik ook aan gedacht, maar dan krijg je "seo-specialisten" die gaan miepen over mogelijk dubbele content.

In dit geval maakt het mij niet zoveel uit, maar ik zoek dus de netste optie

Ik heb voor nu 416 ingesteld, en ik wacht de resultaten af

Misschien een leuke voor A/B/C testing

[Ealanrian]

Is een 204 no content of een 303 see other niet ook een optie?

[Firesphere]

303 sowieso niet, want dat is een permanent, daarom noemde ik 307 al

204 kan ook, maar dan moet ik de pagina returnen, ik wil de gebruiker naar de max-pagina van de paginering doorsturen, dus dat is sowieso een 3xx of 4xx lijkt mij.

[Soultaker]

HTTP 416 lijkt me sowieso fout, want die is bedoeld voor range requests.

Het lijkt me dat 404 gewoon de beste keuze is, aangezien er een pagina is opgevraagd die conceptueel niet bestaat. Dat je toch mooie HTML kunt genereren is wel gebruiksvriendelijk, maar voor de crawler niet interessant, want die pagina bevat verder geen content.

Als je wil redirecten naar de laatste pagina met resultaten kun je het beste een temporary redirect (307) geven, dan snapt de crawler het ook wel. 404 noch 307 impliceren dat de pagina in de toekomst niet kan bestaan.

[Firesphere]

Soultaker schreef op donderdag 30 januari 2014 @ 19:56:
HTTP 416 lijkt me sowieso fout, want die is bedoeld voor range requests.

Het lijkt me dat 404 gewoon de beste keuze is, aangezien er een pagina is opgevraagd die conceptueel niet bestaat. Dat je toch mooie HTML kunt genereren is wel gebruiksvriendelijk, maar voor de crawler niet interessant, want die pagina bevat verder geen content.

Als je wil redirecten naar de laatste pagina met resultaten kun je het beste een temporary redirect (307) geven, dan snapt de crawler het ook wel. 404 noch 307 impliceren dat de pagina in de toekomst niet kan bestaan.

Maar paginering is toch ook een range-request?

[Fish]

google gaat overigens volledig snappen dat er iets is als ?page= en dat het andere content oplevert. en zoniet kun je het iig zo instellen bij de webmastertools,

[Firesphere]

fish schreef op donderdag 30 januari 2014 @ 20:06:
google gaat overigens volledig snappen dat er iets is als ?page= en dat het andere content oplevert. en zoniet kun je het iig zo instellen bij de webmastertools,

Klopt, dat werkt prima, behalve bij out-of-bound requests dus, die markeert Google (en Bing ook trouwens) allemaal als duplicate omdat er behalve de default content geen verschil is tussen alle out-of-bounds.

[Soultaker]

Firesphere schreef op donderdag 30 januari 2014 @ 20:01:
Maar paginering is toch ook een range-request?

Een HTTP range request is een request waarbij de HTTP client een deel van de pagina opvraagt met de Range-header. De 416 Request Range Not Satisfiable foutmelding is specifiek bedoeld voor het geval waarin een client een ongeldige range request heeft gedaan.

Pagineren werkt op een hoger niveau; vanuit het perspectief van het HTTP protocol zijn je pagina's gewoon volledige resources.

[Gomez12]

Firesphere schreef op donderdag 30 januari 2014 @ 20:01:
[...]

Maar paginering is toch ook een range-request?

Waarom vind je bij een 404 dat je wel goede pagina's serveert (ook al heb je geen content) en ga je bij een range request opeens je content wel relevant vinden?

Je content is imho simpelweg "not found" en daar is een status-code voor... (iets met 404)

[Firesphere]

Gomez12 schreef op donderdag 30 januari 2014 @ 20:32:
[...]

Waarom vind je bij een 404 dat je wel goede pagina's serveert (ook al heb je geen content) en ga je bij een range request opeens je content wel relevant vinden?

Je content is imho simpelweg "not found" en daar is een status-code voor... (iets met 404)

Even herlezen

Een out-of-bound request, geeft gewoon een werkende, correcte pagina, met content, alleen geen paginated items onder de default content.

Wat ik precies doe of niet doe, is mijns inziens niet zo interessant, het gaat om de vraag "wat is de beste manier om out-of-bound" af te handelen. En 404 is dan wat mij betreft niet correct, omdat de pagina welzeker bestaat en een niet-lege response kan geven.

[Soultaker]

Wat bedoel je met “content”? Een pagina met wat headers en footers is niet echt content voor een search engine, want die “content” staat al op elke andere pagina.

Zie ook bijvoorbeeld deze pagina op Tweakers.net: http://tweakers.net/nieuw...icht-uit-de-toekomst.html. Daar wordt een nette pagina gegenereerd, maar wel met 404 Not Found response code.

Als je met “content” bedoelt dat je de laastse bestaande pagina weergeeft, dan kun je daar beter naar redirecten met een temporary redirect.

[Firesphere]

Soultaker schreef op donderdag 30 januari 2014 @ 20:48:
Wat bedoel je met “content”? Een pagina met wat headers en footers is niet echt content voor een search engine, want die “content” staat al op elke andere pagina.

Zie ook bijvoorbeeld deze pagina op Tweakers.net: http://tweakers.net/nieuw...icht-uit-de-toekomst.html. Daar wordt een nette pagina gegenereerd, maar wel met 404 Not Found response code.

Als je met “content” bedoelt dat je de laastse bestaande pagina weergeeft, dan kun je daar beter naar redirecten met een temporary redirect.

Ik heb ook wel echte 404's
Ik zoek: redirect met een HTTP-code naar de best beschikbare pagina.

En 404 is fout (pagina bestaat wel, maar is gewoon zinloos, bijvoorbeeld)
Etc.
Ik zoek de beste status.

[Soultaker]

Dan zou ik dus zeggen: een temporary redirect met 302/307.

Ik ben het trouwens nog steeds met je oneens dat de pagina “bestaat”. Als je een artikel met 10 pagina's hebt, dan bestaan pagina 11 dus niet. Ook al ga je die later misschien nog gaat toevoegen, dan bestaat die nu nog niet.

[crisp]

Sebazzz schreef op donderdag 30 januari 2014 @ 19:36:
Tweakers en Bing negeren de te hoge parameter, geven HTTP 200 OK terug, en returnen dan respectievelijk de eerste pagina en laatste pagina

Zo te zien doen we hier op het forum een 301 naar de laatste pagina van een forumtopic; niet ideaal dus...

[chrisO]

Soultaker schreef op donderdag 30 januari 2014 @ 21:00:
[...]

Ik ben het trouwens nog steeds met je oneens dat de pagina “bestaat”. Als je een artikel met 10 pagina's hebt, dan bestaan pagina 11 dus niet. Ook al ga je die later misschien nog gaat toevoegen, dan bestaat die nu nog niet.

Ik ben het hier mee eens. Als je 3000 items hebt, en een bot/bezoeker vraagt de/een pagina op met start=4000, dan bestaan die records niet, als jij vindt dat het dan geen 404 is, omdat die pagina later kan worden toegevoegd, dan zou je theoretisch nooit een 404 kunnen krijgen, want wat je ook opvraagt, het kan later nog worden toegevoegd...

[ Voor 4% gewijzigd door chrisO op 30-01-2014 21:19 ]

[Freeaqingme]

Firesphere schreef op donderdag 30 januari 2014 @ 18:42:
Ik heb een pagina, met zo'n 3000 records, paginering toepassen lijkt me dan wenselijk.

Volgens mij is verbeterde zoek- en filterfunctionaliteit wenselijk. Qua usability ga je niet van je gebruiker verwachten dat ie op pagina 79 een specifiek record opzoekt?

[Firesphere]

Freeaqingme schreef op donderdag 30 januari 2014 @ 21:40:
[...]


Volgens mij is verbeterde zoek- en filterfunctionaliteit wenselijk. Qua usability ga je niet van je gebruiker verwachten dat ie op pagina 79 een specifiek record opzoekt?

Totaal irrelevant jij verward "naar een pagina gaan" met "een pagina kunnen vinden".
Of ik een zoek/filter methode heb is (vooral bij searchbots) niet van toepassing.

In het geval van echte bezoekers is het pebkac. Als je niet snapt dat "laatste", de laatste pagina is, is het een user-error.

[drm]

Het moet gewoon een 404 zijn. Hoe jij de URL of de parameters daarin interpreteert is irrelevant, de URL stelt een resource voor, maar die resource bestaat niet, hence Resource not found. Of dat dan komt door een foute parameter of een spelfout boeit niet, jij hebt geen content die bij die URL hoort, dus 404.

[Firesphere]

drm schreef op donderdag 30 januari 2014 @ 21:53:
Het moet gewoon een 404 zijn. Hoe jij de URL of de parameters daarin interpreteert is irrelevant, de URL stelt een resource voor, maar die resource bestaat niet, hence Resource not found. Of dat dan komt door een foute parameter of een spelfout boeit niet, jij hebt geen content die bij die URL hoort, dus 404.

Dat is dus mijn hele vraag
De resource bestaat wel, maar is niet uniek en is vooral overbodig. Dat maakt de resource niet een "not found"

Vandaar dat ik dus graag wil uitvinden, welke status past het beste?
Ik heb nu een 416 ingesteld, maar ik ga een A/B test toepassen, kijken welke het beste is achteraf

404 staat ook op de lijst van statussen trouwens

[Gtoniser]

Firesphere schreef op donderdag 30 januari 2014 @ 22:01:
[...]
Vandaar dat ik dus graag wil uitvinden, welke status past het beste?
Ik heb nu een 416 ingesteld, maar ik ga een A/B test toepassen, kijken welke het beste is achteraf

Zoals eerder al vermeld is een 416 totaal niet van toepassing hier. Dat gaat over Range-requests van een bestand die fout gaan (je vraagt bijvoorbeeld byte 300 en verder op van een bestand terwijl het bestand maar 200 bytes is). Als je geen 404 wilt gebruiken moet je het zelf weten, maar een 416 slaat nergens op.

[Firesphere]

Gtoniser schreef op donderdag 30 januari 2014 @ 22:05:
[...]

Zoals eerder al vermeld is een 416 totaal niet van toepassing hier. Dat gaat over Range-requests van een bestand die fout gaan (je vraagt bijvoorbeeld byte 300 en verder op van een bestand terwijl het bestand maar 200 bytes is). Als je geen 404 wilt gebruiken moet je het zelf weten, maar een 416 slaat nergens op.

No offence, maar jouw reactie slaat nergens op.
Ik vraag heel simpel "welke is de beste". Ik zeg niet "Ik wil perse 416 gebruiken".

Gedurende de hele conversatie, verander ik van mening, omdat ik zelf niet weet welke de beste is/was.

Het enige dat ik zeker weet, is dat een 404 niet de oplossing is in dit geval.

[Sebazzz]

crisp schreef op donderdag 30 januari 2014 @ 21:12:
[...]

Zo te zien doen we hier op het forum een 301 naar de laatste pagina van een forumtopic; niet ideaal dus...

Niet in de topiclijst.

[Douweegbertje]

Firesphere schreef op donderdag 30 januari 2014 @ 22:01:
[...]

Dat is dus mijn hele vraag
De resource bestaat wel, maar is niet uniek en is vooral overbodig. Dat maakt de resource niet een "not found"

Vandaar dat ik dus graag wil uitvinden, welke status past het beste?
Ik heb nu een 416 ingesteld, maar ik ga een A/B test toepassen, kijken welke het beste is achteraf

404 staat ook op de lijst van statussen trouwens

Het is volgens mij vrij simpel. Ten eerste geef je aan dat je eigenlijk geen 404 wilt, omdat er content staat. Nou dat is ook prima, en dan laat je de pagina zo met de inhoud "dit item bestaat niet". In feite vang je het dan zo af. Als je echt wilt mierenneuken, is dat niet de beste oplossing. Immers zou een gebruiker er bij normaal gebruikt -nooit- op moeten komen. Daarom is het helemaal niet zo gek om er een 404 van te maken.

Dan het argument van "google ziet de 404 en indexed hem niet meer".
Dat is eigenlijk niet waar, google gaat niet domweg een +1 bij je parameter gooien. En ook al zou hij dat doen, dan is hij slim genoeg om in te zien dat het item niet bestaat (zoals de 404 aangeeft). Eigenlijk komt google alleen bij pagina's die bereikbaar zijn, oftewel via links.

Maar je kunt beter voor een betere oplossing gaan

code:

<link rel="canonical" href="http://blaat.nl/bekijk-alles"/>

Dat in je header zetten bij je pagination. Dat is een link naar het totaal overzicht. Zo wordt je beter geïndexeerd.


Andere oplossing is

code:

rel="prev"
Of
rel="next"

mee geven aan je pagination. Google herkend dit, en zo voorkom je dat hij op een pagina komt die een 404 is.


tl;dr

gewoon 404 doen, en zorgen dat je een bot "richting geeft".
Als je meuk goed in elkaar zit, dan komt dat helemaal goed.

Je bent alleen de sjaak als je een link hebt, naar een 404 pagina.

[ Voor 4% gewijzigd door Douweegbertje op 30-01-2014 22:19 ]

[Gtoniser]

Firesphere schreef op donderdag 30 januari 2014 @ 22:15:
[...]

Ik vraag heel simpel "welke is de beste". Ik zeg niet "Ik wil perse 416 gebruiken".

Het enige wat ik probeer duidelijk te maken is dat een http 416 geen optie is om te gebruiken, omdat dit niet over de pagina gaat maar over het http request.

[Cartman!]

Ik sluit me aan bij t 404-kamp. De pagina bestaat nu niet maar mogelijk over een jaar wel dus wil je geen 404 gebruiken. Dat ga je nooit van tevoren weten dus dan zou 404 eigenlijk door niemand gebruikt moeten worden volgens die redenatie en dat is gek.

Wat een pagina verder voor inhoud heeft staat verder los van de status code. Het gebruiken van een code als 416 is nu gewoon een verkapte 404 omdat de beschrijving van die code het woord range in zich heeft wat je linkt aan paginatie.

[Gomez12]

Firesphere schreef op donderdag 30 januari 2014 @ 20:36:
[...]
Een out-of-bound request, geeft gewoon een werkende, correcte pagina, met content, alleen geen paginated items onder de default content.

Wat is dan voor jou een 404? Want met server-side talen bestaan bij mijn meeste oplossingen zo ongeveer alle pagina's.

Ik implementeer over het algemeen een router die je over het algemeen doorstuurt naar een view die een header pakt, een stuk content en een footer (even heel simpel gezegd) en dit aan je serveert.
Header en footer bestaan in principe altijd wel en leveren op zich ook een werkende correcte pagina op. Maar toch serveer ik 404's als ik geen content-handler heb of als ik simpelweg geen content heb.

Ik ga altijd uit van de content. Heb ik geen content die voldoet aan de criteria dan is het gewoon een 404

Uitgaan van een werkende correcte pagina vind ik ook vreemd, zelfs een 404-pagina is op zichzelf een werkende correcte pagina ( of je moet echt en alleen maar een 404 header versturen en nul pagina data )
Een 3xx header vind ik ook ietwat raar, want de content staat in dit geval niet ergens anders, je hebt het gewoon niet.

[drm]

Firesphere:
[...]

Dat is dus mijn hele vraag
De resource bestaat wel, maar is niet uniek en is vooral overbodig. Dat maakt de resource niet een "not found"

nee, je resource betaat niet in termen van HTTP. Dat jij onderdelen van de URL gebruikt voor paginering is totaal irrelevant.

416 slaat echt helemaal nergens op. Lees de rfc er op na:

quote: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)

When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.

[Firesphere]

Aangezien het 404-kamp hier groots aanwezig is, ga ik ook maar voor de 404.

Ik kan me er op zich ook wel in vinden, het is natuurlijk wel een "Resource found, but utterly unwanted" om het zo te zeggen.

[NMe]

Ik snap het probleem sowieso niet. Google komt nooit uit bij een link die out of bounds gaat tenzij je zélf naar die pagina hebt lopen linken op je site. Zorg dat jouw paginering goed werkt en je gaat hooguit een 404 aan Google serveren als er ergens een menselijke fout gemaakt wordt in het copy/pasten of overtikken van een link (op een externe site).

Daarbij:

Firesphere schreef op donderdag 30 januari 2014 @ 19:22:
Maar aan de andere kant, is het technisch gezien geen 404. Het is een 200 met de volledige lay-out, werkend, maar geen content omdat de ArrayList leeg is.

Dan pas je dat toch aan? Leeg result = 200, leeg result maar wél resultaat op de zoektermen zonder de opgegeven range = 404.

[Cartman!]

Firesphere schreef op vrijdag 31 januari 2014 @ 20:18:
Aangezien het 404-kamp hier groots aanwezig is, ga ik ook maar voor de 404.

Ik kan me er op zich ook wel in vinden, het is natuurlijk wel een "Resource found, but utterly unwanted" om het zo te zeggen.

Nee, de resource is helemaal niet gevonden want de gevraagde content bestaat niet in je database.

[R4gnax]

Firesphere schreef op vrijdag 31 januari 2014 @ 20:18:
Aangezien het 404-kamp hier groots aanwezig is, ga ik ook maar voor de 404.

Ik kan me er op zich ook wel in vinden, het is natuurlijk wel een "Resource found, but utterly unwanted" om het zo te zeggen.

Nee er is helemaal geen resource gevonden. De conceptuele resource waarnaar jouw gepagineerde URL verwijst betreft de gepagineerde items. Noch stukjes uitleg die op elke pagina van deze set herhaald worden, noch standaard website header/footer behoort tot de daadwerkelijke content die door die ene URL uniek geidentificeerd wordt.

De enige juiste status code hier is 404 Not Found, wat betekent dat een resource tijdelijk niet beschikbaar is, maar het een client toegestaan is om het op een later tijdstip nog eens te proberen. Een resource die nooit meer terug komt geef je daarentegen aan met 410 Gone.

Als je echt echt principieel bezwaar hebt tegen het gebruik van 404, dan zou je nog weg kunnen komen met de 422 Unprocessable Entity code uit de WebDAV extensies, maar dat is een extensie die niet gegarandeerd ondersteund hoeft te worden door alle software waarmee jouw site gaat communiceren. (Browsers, proxies, etc.)

[ACM]

Het lijkt me sowieso geen goed idee om hele exclusieve statuscodes te gebruiken. Juist voor zoekmachines is het handig zoveel mogelijk de meestgebruikte codes aan te houden. Het lijkt me weinig zin hebben om een statuscode te gebruiken die dan uiteindelijk op een grote "hoop" (4xx die we niet snappen) wordt gegooid, terwijl er voor 404 waarschijnlijk veel beter met "maar nu kennen we het wel"-situaties kan worden omgegaan.

Als je graag wilt dat Google en co je extra paginanummers op korte termijn weer proberen; geef dan domweg een korte expiry-tijd mee via de caching headers.

Het is natuurlijk het mooist als je domweg voorkomt dat crawlers die url uberhaupt tegenkomen, zodat ze nooit een "verkeerde" response kunnen bewaren.

[Firesphere]

ACM schreef op zaterdag 01 februari 2014 @ 15:36:
Het is natuurlijk het mooist als je domweg voorkomt dat crawlers die url uberhaupt tegenkomen, zodat ze nooit een "verkeerde" response kunnen bewaren.

Je kan helaas niet voorkomen dat crawlers get-parameters gaan crawlen "at random".
Googlebot en Bingbot bijvoorbeeld, zien ?start=10, ?start=20 etc....
En bedenken dan "Och, we proberen ?start=400000 ook even"

Ik ben uiteindelijk toch maar voor de 404 gegaan .
Maar ik vond het wel een aardig vraagstuk, en gezien de reacties klopt dat ook aardig

[ACM]

Firesphere schreef op zaterdag 01 februari 2014 @ 16:00:
Je kan helaas niet voorkomen dat crawlers get-parameters gaan crawlen "at random".
Googlebot en Bingbot bijvoorbeeld, zien ?start=10, ?start=20 etc....
En bedenken dan "Och, we proberen ?start=400000 ook even"

Ik heb die opmerking wel vaker gezien, maar de keren dat ik onze 404's e.a. bekijk zag k dat niet terug.

Desalniettemin zijn statuscodes maar rare dingen, zeker omdat ze heel erg gericht zijn op het http-protocol zelf en weinig hulp bieden voor webapplicaties.

[Firesphere]

ACM schreef op zaterdag 01 februari 2014 @ 16:10:
[...]

Ik heb die opmerking wel vaker gezien, maar de keren dat ik onze 404's e.a. bekijk zag k dat niet terug.

Desalniettemin zijn statuscodes maar rare dingen, zeker omdat ze heel erg gericht zijn op het http-protocol zelf en weinig hulp bieden voor webapplicaties.

Ik zie het dus wel terug in m'n Webmastertools

[Voutloos]

En ik zie dat ook nooit bij diverse sites. Zonder welles/nietes spelletje te beginnen: Ik zou toch echt kijken waar die links gevonden worden als 't structureel is.

[Firesphere]

Ik heb't idee dat het aan de get-parameter ligt. Dat als die numeriek is, de bots zelf ophogen want wie weet bestaat die.
Ik zie dit bij meerdere sites (niet alleen m'n eigen )

Hoewel buiten de scope van de originele vraag.

[RobIII]

Firesphere schreef op zaterdag 01 februari 2014 @ 16:23:
Ik heb't idee dat het aan de get-parameter ligt. Dat als die numeriek is, de bots zelf ophogen want wie weet bestaat die.

Ja, want ze hebben nog niet genoeg te doen crawlen

Een beetje bot (Google/Bing) doet dat echt niet; hooguit een malafide bot. Niets om je druk om te maken. Tenzij je dus zelf ergens links naar die nietbestaande paginanummers maakt. Dus als je een googlebot o.i.d. op zulke pagina's aantreft dan ben je hoogstwaarschijnlijk zelf schuld (of een derde partij/site die linkt naar nietbestaande pagina's).

[ Voor 24% gewijzigd door RobIII op 01-02-2014 16:31 ]

[PierreAronnax]

Doorgaand op de oorspronkelijke vraag, wat is de meest geschikte status code voor een zoekresultaten pagina zonder resultaten?

http://tweakers.net/zoeken?keyword=blablablabla geeft de melding 'Helaas, geen resultaten gevonden.' met een 200-status. Was een 404-status hier ook niet geschikter geweest?

[Firesphere]

RobIII schreef op zaterdag 01 februari 2014 @ 16:30:
[...]

Ja, want ze hebben nog niet genoeg te doen crawlen

Een beetje bot (Google/Bing) doet dat echt niet; hooguit een malafide bot. Niets om je druk om te maken. Tenzij je dus zelf ergens links naar die nietbestaande paginanummers maakt. Dus als je een googlebot o.i.d. op zulke pagina's aantreft dan ben je hoogstwaarschijnlijk zelf schuld (of een derde partij/site die linkt naar nietbestaande pagina's).

Toch zie ik ?start=4580 in de canonical lijst staan van bijvoorbeeld Google Webmastertools. Terwijl ik NERGENS daar aan refereer. (In mijn geval)
Maar ook andere sites waar een dergelijke parameter voorkomt, terwijl er op de hele site ook niet wordt gerefereerd aan dat startnummer.

[Fish]

mischien wel in het verleden. is dat mogelijk ?

(minder items op een pagina oid)

[ Voor 27% gewijzigd door Fish op 01-02-2014 20:41 ]

[Freeaqingme]

PierreAronnax schreef op zaterdag 01 februari 2014 @ 16:39:
Doorgaand op de oorspronkelijke vraag, wat is de meest geschikte status code voor een zoekresultaten pagina zonder resultaten?

http://tweakers.net/zoeken?keyword=blablablabla geeft de melding 'Helaas, geen resultaten gevonden.' met een 200-status. Was een 404-status hier ook niet geschikter geweest?

Nee. De resultatenpagina kon gewoon gevonden en geserveerd worden. Het feit dat er geen resultaten getoond kunnen worden doet daar niets aan af.

[NMe]

Firesphere schreef op zaterdag 01 februari 2014 @ 16:16:
[...]

Ik zie het dus wel terug in m'n Webmastertools

Sorry, maar dat is bullshit. Dan zit er toch echt iemand - jijzelf of een externe site - te linken naar een pagina die niet (meer) bestaat. Google gaat écht niet lopen kunstelen met het zelf aanpassen van numerieke get-parameters...

Freeaqingme schreef op zaterdag 01 februari 2014 @ 22:26:
[...]

Nee. De resultatenpagina kon gewoon gevonden en geserveerd worden. Het feit dat er geen resultaten getoond kunnen worden doet daar niets aan af.

Je hebt gewoon een resultaat gevonden op die zoekopdracht. Dat dat resultaat een lege tabel oplevert doet er niet aan af dat de pagina binnenkomt via een normaal/correct request en je query netjes uitgevoerd kan worden. Dat is IMO een totaal andere situatie dan geen content vinden omdat iemand je range buiten bereik heeft gebracht.

[ Voor 42% gewijzigd door NMe op 02-02-2014 01:52 ]

[Firesphere]

NMe schreef op zondag 02 februari 2014 @ 01:50:
[...]

Sorry, maar dat is bullshit. Dan zit er toch echt iemand - jijzelf of een externe site - te linken naar een pagina die niet (meer) bestaat. Google gaat écht niet lopen kunstelen met het zelf aanpassen van numerieke get-parameters...

Zullen we ruilen van WMT login?
Dat jij het nog niet eerder hebt gezien maakt het niet onwaar.

[Verwijderd]

Kun je s.v.p. de access logs van die requests eens posten? Ik ben met name benieuwd naar de requests van die crawler voor en na die "out of bounds" requests. De referrer wordt door de meeste crawlers netjes meegegeven.

[Gomez12]

Firesphere schreef op zondag 02 februari 2014 @ 02:49:
[...]

Zullen we ruilen van WMT login?
Dat jij het nog niet eerder hebt gezien maakt het niet onwaar.

Maar dat jij het wel ziet maakt het nog niet zo dat Google gaat zitten gokken.

Wellicht dat jij er wel een link naar had staan voor testing op het moment dat er een spider langskwam en bij de volgende spider-run had je die weer weggehaald.
Wellicht dat je user-content op die site toestaat waar ergens die link instaat.
Wellicht dat je paging-mechanisme toch nog een link genereert alleen zie je die niet

ACM schreef op zaterdag 01 februari 2014 @ 16:10:
[...]

Ik heb die opmerking wel vaker gezien, maar de keren dat ik onze 404's e.a. bekijk zag k dat niet terug.

Maar dat is toch ook weer logisch als jullie 301 headers versturen? Zie :

crisp schreef op donderdag 30 januari 2014 @ 21:12:
[...]

Zo te zien doen we hier op het forum een 301 naar de laatste pagina van een forumtopic; niet ideaal dus...

[NMe]

Firesphere schreef op zondag 02 februari 2014 @ 02:49:
[...]

Zullen we ruilen van WMT login?
Dat jij het nog niet eerder hebt gezien maakt het niet onwaar.

Je ziet het vekeerd. Dat Google die dingen in je webmaster tools laat zien wil niet zeggen dat de bot zélf die URL gefabriceerd heeft. Die kán alleen in de WMT-logs terechtgekomen zijn als je er zelf naar gelinkt hebt of als iemand buiten de site dat gedaan heeft.

[Firesphere]

Verwijderd schreef op zondag 02 februari 2014 @ 03:38:
Kun je s.v.p. de access logs van die requests eens posten? Ik ben met name benieuwd naar de requests van die crawler voor en na die "out of bounds" requests. De referrer wordt door de meeste crawlers netjes meegegeven.

Hoewel (wederom/nog steeds) totaal irrelevant, het gaat me niet om "mijn" site, maar de simpele vraag "als het gebeurd, wat is de beste status-code om door te verwijzen".
Waarom het zo specifiek op deze site moet worden toegepast is me even een raadsel.
Maargoed.
66.249.66.117 - - [02/Feb/2014:00:56:51 +0100] "GET /zenders/zender/ned3?start=8300 HTTP/1.1" 302 5464 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Het enige dat ik kan bedenken, is dat er gepagineerde objecten zijn die WEL zo ver doorlopen, en daarom aangenomen wordt dat ze het allemaal kunnen.
Maar het blijft vreemd. De 302 lijkt van Cloudflare te komen, ik zet zelf een 404 namelijk.

NMe schreef op zondag 02 februari 2014 @ 12:06:
[...]

Je ziet het vekeerd. Dat Google die dingen in je webmaster tools laat zien wil niet zeggen dat de bot zélf die URL gefabriceerd heeft. Die kán alleen in de WMT-logs terechtgekomen zijn als je er zelf naar gelinkt hebt of als iemand buiten de site dat gedaan heeft.

Dat is dus niet waar.

Further still - it may attempt to "guess" at URLs ... if G see's you have 20 pages in sequence (page1, page2, page3) it may go looking to see if there is a page21 and page22 etc.
It may also be looking at any Forms on your site ... as in some cases, Googlebot may use a form to explore your site.

[Verwijderd]

Firesphere schreef op zondag 02 februari 2014 @ 13:18:

Hoewel (wederom/nog steeds) totaal irrelevant, het gaat me niet om "mijn" site, maar de simpele vraag "als het gebeurd, wat is de beste status-code om door te verwijzen".

Niet doorverwijzen en een 404 geven. Doorverwijzen is bullshit. De pagina bestaat niet, maar iets of iemand wil specifiek die pagina. Dan moet je zeggen "die is er niet" en niet "die is er niet maar misschien vind je dit ook interessant". Het is niet voor niets dat je Location headers niet moet/kan combineren met een 4xx status code.

Dat gezegd hebbende is een 303 met Location header het beste alternatief als je toch wilt redirecten naar de laatste pagina. Een 200 met een andere pagina serveren is uit den boze.

[Grijze Vos]

Firesphere schreef op donderdag 30 januari 2014 @ 19:41:
Heb ik ook aan gedacht, maar dan krijg je "seo-specialisten" die gaan miepen over mogelijk dubbele content.

Canonical URL meegeven.

Persoonlijk zou ik gewoon een 404 geven, je komt er immers alleen als je met de hand gaat kutten met de URL. Ik vind dan een early exit met een foutcode acceptabel.

[Freeaqingme]

Was een 404-status hier ook niet geschikter geweest?

Freeaqingme schreef op zaterdag 01 februari 2014 @ 22:26:


Nee. De resultatenpagina kon gewoon gevonden en geserveerd worden. Het feit dat er geen resultaten getoond kunnen worden doet daar niets aan af.

Je hebt gewoon een resultaat gevonden op die zoekopdracht. Dat dat resultaat een lege tabel oplevert doet er niet aan af dat de pagina binnenkomt via een normaal/correct request en je query netjes uitgevoerd kan worden. Dat is IMO een totaal andere situatie dan geen content vinden omdat iemand je range buiten bereik heeft gebracht.

Blij dat we er hetzelfde over denken

[ Voor 9% gewijzigd door Freeaqingme op 02-02-2014 16:19 ]