Onderwerp: Zoekmachines

robert wrote:

> Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> > Daniel Tryba:
> >
> >>Ik wacht nog steeds op het antwoord hoe google dynamische paginas
> >>herkent. A
> >
> > Dat hebben we alleen al in deze thread inmiddels 3 keer uitgelegd. Dit
> > begint een beetje saai te worden.
>
> "Google herkent bepaalde patronen in URLs. ?id= enzo."
>
> Statische HTML pagina's kan je net zo goed dergelijke 'patronen' meegeven
> (voor het clientside parsen van die dingen bijvoorbeeld),

Met als (waarschijnlijke) gevolg dat ze langzamer worden geindexeerd.

> en dynamische
> HTML pagina's gebruiken niet per definitie zulke 'patronen'.

Met als gevolg dat ze als "statische" pagina's worden geindexeerd.

Dus door een statische pagina als dynamisch te vermomen voor Google
wordt er langzaam geindexeerd, door een dynamische pagina als statisch
te vermomen wordt deze "normaal" geindexeerd.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

John Bokma <postmaster@castleamber.com>:
> robert wrote:
>
>> "Google herkent bepaalde patronen in URLs. ?id= enzo."
>>
>> Statische HTML pagina's kan je net zo goed dergelijke 'patronen'
>> meegeven (voor het clientside parsen van die dingen bijvoorbeeld),
>
> Met als (waarschijnlijke) gevolg dat ze langzamer worden geindexeerd.
>
>> en dynamische HTML pagina's gebruiken niet per definitie zulke
>> 'patronen'.
>
> Met als gevolg dat ze als "statische" pagina's worden geindexeerd.
>
> Dus door een statische pagina als dynamisch te vermomen voor Google
> wordt er langzaam geindexeerd, door een dynamische pagina als statisch
> te vermomen wordt deze "normaal" geindexeerd.

Het ging erover hoe Google dynamische pagina's kan herkennen, niet over hoe
Google er mee omgaat.

--
robert

robert wrote:

> John Bokma <postmaster@castleamber.com>:
> > robert wrote:
> >
> >> "Google herkent bepaalde patronen in URLs. ?id= enzo."
> >>
> >> Statische HTML pagina's kan je net zo goed dergelijke 'patronen'
> >> meegeven (voor het clientside parsen van die dingen bijvoorbeeld),
> >
> > Met als (waarschijnlijke) gevolg dat ze langzamer worden geindexeerd.
> >
> >> en dynamische HTML pagina's gebruiken niet per definitie zulke
> >> 'patronen'.
> >
> > Met als gevolg dat ze als "statische" pagina's worden geindexeerd.
> >
> > Dus door een statische pagina als dynamisch te vermomen voor Google
> > wordt er langzaam geindexeerd, door een dynamische pagina als statisch
> > te vermomen wordt deze "normaal" geindexeerd.
>
> Het ging erover hoe Google dynamische pagina's kan herkennen, niet over hoe
> Google er mee omgaat.

Rene? Neem jij het even over, ik ga slapen...

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

John Bokma <postmaster@castleamber.com> wrote:
>>>"1. Reasons your site may not be included.
>>>
>>> * Your pages are dynamically generated. We are able to index
>>>dynamically generated pages. However, because our web crawler can easily
>>>overwhelm and crash sites serving dynamic content, we limit the amount
>>>of dynamic pages we index.
>>>"
>>>
>>>Maar ik vrees dat je het nog steeds niet begrijpt.
>>
>> Ik wacht nog steeds op het antwoord hoe google dynamische paginas
>> herkent. Aan de vorm van de url is het niet te zien.
>
> Google neemt (o.a) aan dat een pagina dynamisch is, als de URL een
> bepaalde vorm heeft.

Aha, bovenstaande tekst van google is dus gewoon foutief opgestelt:
s/Your pages are dynamically/We assume your pages are dynamically/

>> Dus /fotos/vakanties/1986/Opper-Volta levert gegarandeerd de gewenste
>> resultaten op (fotos van dat land uit 1986). Of is het OpperVolta, of
>> toch maar Burkinafaso?
>
> Een tip, is om in URIs geen uppercase letters te gebruiken, om
> verwarringen te voorkomen. Maar je snapt dat een willekeurig id gokken
> nog minder kans geeft op resultaten?

Nee. De kans dat een willekeurig gekozen jaartal plus landnaam is IMHO
lager, aangezien er meer variabelen zijn die nu ook nog eens van elkaar
afhangen (om maar te zwijgen van de tijdsafhankelijkheid van de
landnamen zelf).

> Als id=399 foto's geeft, wat is de kans dat id=400 foto's geeft?

50%

> Echter, de kans dat:
>
> /fotos/
> /fotos/1999/
> /fotos/1999/vakanties
>
> allemaal een index pagina geven met een overzicht is groot als de
> webbouwer verstand van zaken heeft. En in de praktijk werkt dit
> inderdaad erg vaak, tenminste ik hack nogal eens URLs :-D.

Mijn ervaring is dat je in heel veel gevallen een mooie melding krijgt
dat je daar niet mag komen.

>>>Uiteraard kent elke website bezoeker ook alle belangrijke IP nrs uit
>>>zijn of haar hoofd.
>>
>> Voor websites is dat nauwelijks interessant, virtualhosts zijn namelijk
>> afhankelijk van een naam.
>
> Dat hangt helemaal af van de gebruikte techniek. Bij meer dan 1 website
> op 1 machine spreekt men van virtual hosting. En je kan meer dan 1 IP
> nr, dus 1 per virtual host, op 1 machine gebruiken. Meestal moet je daar
> extra voor betalen, overigens.

Rare definitie van virtualhost... Voorbeeld: mijn firewall heeft 4
IPv4 nummers, elke netwerkkaart 1, er dus helemaal niets virtueels aan
meerdere ips op die machine. Wat jij beschrijft ken ik onder de naam "ip
aliasing" en komt erop neer dat je een netwerkkaart meerdere ipnummers
geeft, zo heeft de netwerkkaart die de chello uplink regelt 4 publieke IPv6
nummers waarvan 3 in het zelfde netwerksegment.

>> Dan vraag ik me toch af waarom het subject al sinds het being
>> "zoekmachines" is... Ik zou wat later opstaan John, het nog veel te
>> vroeg voor je, _jij_ bent de persoon die begon over de wat gebruikers
>> zinniger vinden als url.
>
> Nee, ik begon over wat zoekmachines als Google zinnig vinden als URL, en
> dat je een URL *en* Google vriendelijk kan maken (lees: vaker
> indexeren), *en* ook nog eens vriendelijk voor de bezoeker kan maken.

<q src='408ead09$0$196$58c7af7e@news.kabelfoon.nl'>
> Simpel, zet op een voor zoekmachines bereikbare plek URLs neer...
> Een zoekmachine boeit het niet hoe paginas worden gegenereerd, als een
> url maar iets zinnigs oplevert.

Dat boeit dus wel.
[http://www.google.com/webmasters/2.html#A1]
http://johnbokma.com/mexit/2004/04/1...forgoogle.html
</q>

MAW je herhaalde mijn opmerking nog maar eens dat URL iets zinnigs moet
opleveren.

> Overigens woon ik in een totaal andere tijdzone :-D.

Goh! Anders zou ik wel laat hebben geschreven.

>>>>Daar boeit de vorm van hostname niet.
>>>
>>>Alweer mis. Ook de vorm van de hostname is belangrijk voor een
>>>zoekmachine. Trefwoorden in hostname cq. domainname, cq. de URI tellen
>>>namelijk *ook* mee. Nog een reden om /fotos/1999/vakanties/srilanka
>>>te verkiezen boven /script?id=12132334
>>
>> Niet voor de inhoud, alleen voor wegingsfactoren in rang. Maar dat is
>> helemaal niet interessant indien je paginas niet worden geindexeerd
>> omdat google denkt dat ze dynamisch zijn. En dat indexeren was de vraag
>> van de OP.
>
> Dus het boeit allemaal wel.

Indexeren is de stap na spideren. Je kunt uit de index van google geen
resultaten krijgen als google de url niet eerst gespiderd heeft, en als
die spider weigert om urls te op te halen "uit zelfbescherming" heeft de
manier waarop google wegeingsfactoren geeft aan trefwoorden in de URI
natuurlijk geen enkele invloed op het niet gevonden resultaat.

>>>En van wie is het dus een keuze? Juist! Van de WEBSITE eigenaar. Snap je
>>>het nu?
>>
>> Nee. Als je wilt dat je inhoud gevonden wordt door de monopolist google
>> heb je geen keuze.
>
> Jawel, alleen het indexeren gaat langzamer. De website eigenaar kan zelf
> het beste beoordelen of Google als een gek een dynamisch deel mag
> indexeren, of dat dit liever rustig gebeurd.

Als googlebot als een gek paginas opvraagt dan dienen de programmeurs
daarvan naar een heropvoedingscursus te worden gestuurd. Ze zijn nu
immers aan symptoombestrijding bezig ipv van de oorzaak aan te pakken.

>>>"However, because our web crawler can easily overwhelm and crash sites
>>>serving dynamic content, we limit the amount of dynamic pages we index."
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Limiet op aantal, niet op snelheid.
>
> Fout! Er staat duidelijk *our web crawler can easily overwhelm and crash
> sites*. Hoe kan dat? Door het in hoog tempo ophalen van een flink aantal
> pagina's *per bezoek*. En daarom: "we limit the amount of dynamic pages
> we index" PER BEZOEK.

het is leuk dat je het woord "per bezoek" erzelf bij verzint.

>> MAW als je wilt dat
>> alles wordt geindexeerd door de searchengine die momenteel een bijna
>> monopolistisch marktaandeel heeft moet je de criteria achterhalen waarom
>> google denkt dat iets dynamisch is. En dat is aan de url niet te zien...
>
> Of het werkelijk dynamisch is, is inderdaad niet aan de vorm te zien.
> Sterker, als het dynamisch is, zijn er massa's truuks om het altijd
> statisch te presenteren, en omgekeerd. Dus hanteerd Google een ander
> criteria.

Maar in deze hele thread is dat criteria dan nog niet aan bod
gekomen... Ik moet mijn vraag dus maar weer herhalen: Hoe herkent google
dynamische paginas, aan de url is het immers niet te zien.

>> En het wordt al helemaal ingewikkeld als je over een tijdje al je urls
>> op een andere manier moet rewriten of je output moet gaan veranderen om
>> in de volgende meest gebruikte se te komen.
>
> Ja, en stel je voor dat die zoekmachine alle URLs met id= er in gaat
> uitsluiten. Ben je ook mooi zuur.

Dan heeft die searchengine verdomt weinig content, het aantal zinnig
zoekresultaten zal dan ook achterblijven met concurenten.

--

Daniel Tryba

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Ik wacht nog steeds op het antwoord hoe google dynamische paginas
>>herkent. A
>
> Dat hebben we alleen al in deze thread inmiddels 3 keer uitgelegd. Dit
> begint een beetje saai te worden.

Schijnbaar krijg je meer artikelen te lezen dan ik op deze nieuwsserver
krijg of dan in googles archief staan.

--

Daniel Tryba

John Bokma <postmaster@castleamber.com> wrote:
> [ dingen die niet werken zoals gedocumenteerd ]
>
>> Klopt. En soms is het helaas mogelijk. Je kan of een feature vermijden,
>> of er om heen hacken en scherp blijven.
>
> Dat moet onmogelijk zijn, natuurlijk :-D.

Mijn werkgever stelt het helemaal niet op prijs dat ik om fouten van
externe partijen heen ga hacken, immers heb je op dat moment 2
problemen:
-je moet je eigen werknemers tijd laten besteden aan het oplossen van
het probleem (kost geld)
-de externe partij heeft slecht werk geleverd en dus niet de afgesproken
waar het geld.

Bij deze beschrijving komen enkele goed Dilberts in mijn gedachten op.

--

Daniel Tryba

Daniel Tryba:
>Rene Pijlman:
>>>Ik wacht nog steeds op het antwoord hoe google dynamische paginas
>>>herkent. A
>>
>> Dat hebben we alleen al in deze thread inmiddels 3 keer uitgelegd. Dit
>> begint een beetje saai te worden.
>
>Schijnbaar krijg je meer artikelen te lezen dan ik op deze nieuwsserver
>krijg of dan in googles archief staan.

GGHAAaahpff.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

NNTP-Posting-Host: toad.stack.nl
X-Trace: news.tue.nl 1083153703 11704 131.155.140.135 (28 Apr 2004 12:01:43 GMT)
X-Complaints-To: abuse@tue.nl
NNTP-Posting-Date: Wed, 28 Apr 2004 12:01:43 +0000 (UTC)
User-Agent: tin/1.5.11-20020419 ("Toxicity") (UNIX) (FreeBSD/4.9-STABLE (i386))
Xref: nl-news.euro.net nl.internet.www.server-side:34832

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>> Dat hebben we alleen al in deze thread inmiddels 3 keer uitgelegd. Dit
>>> begint een beetje saai te worden.
>>
>>Schijnbaar krijg je meer artikelen te lezen dan ik op deze nieuwsserver
>>krijg of dan in googles archief staan.
>
> GGHAAaahpff.

Tip: eerder naar bed en later opstaan.

Zelfs John heeft het licht al gezien:
<q src='http://groups.google.com/groups?selm=408eef5f%240%24188%2458c7af7e%40news.k abelfoon.nl'>
> de criteria achterhalen waarom google denkt dat iets dynamisch is. En
> dat is aan de url niet te zien...

Of het werkelijk dynamisch is, is inderdaad niet aan de vorm te zien.
Sterker, als het dynamisch is, zijn er massa's truuks om het altijd
statisch te presenteren, en omgekeerd. Dus hanteerd Google een ander
criteria.
</q>

Dus hou ons nou niet langer in spanning, anders heb ik straks ook last
van een slechte nachtrust.

--

Daniel Tryba

X-Newsreader: Forte Agent 1.91/32.564
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 37
NNTP-Posting-Host: 213.84.170.149
X-Trace: 1083155090 dreader12.news.xs4all.nl 97878 [::ffff:213.84.170.149]:9786
Xref: nl-news.euro.net nl.internet.www.server-side:34837

On Tue, 27 Apr 2004 14:59:46 -0500, John Bokma
<postmaster@castleamber.com> wrote in nl.internet.www.server-side in
message <408ebbb2$0$195$58c7af7e@news.kabelfoon.nl> with the subject:
Re: Zoekmachines:

>Welke URL is nu mooier voor een gebruiker?
>
>/showpage?id=13131547
>
>of
>
>/fotos/vakanties/1999/srilanka/

Uiteraard is de tweede gemakkelijker voor de gebruiker. Hij kan uit de
url de inhoud afleiden. Om een hoge plaats in zoekmachines te krijgen,
is de laatste url ook veel beter. Als je er nu
foto/vakantie/sri_lanka/ van maakt en er voor zorgt dat in <title> en
<h1> ook de woorden "foto" "vakantie" "1999" en "Sri Lanka" ben je
verzekerd van een hoge plaats als iemand zoekt op "foto vakantie 1999
sri lanka"

Doegie,
Jaap.




--
************************************************** *****
Homo bureaucrasis: survival of the fittest?
************************************************** *****

Jaap van Wingerde
e-mail: 1234567890@xs4all.nl
Internet: http://www.vanwingerde.net/jaap/

Daniel Tryba wrote:
>>Ja, *zou*. Echter, o.a. Google maakt wel degelijk onderscheid. En hoe
>>maak jij je websites?
>
>
> Ik maak helemaal geen websites. De laatste is almeer dan 3 jaar geleden.

Heb je wel relevante ervaring met het laten indexeren van pagina's door
Google dan ?

>
>
>>Op wat *zou* moeten, of de werkelijkheid?
>
>
> Tot de frustratie van de project manager maakt ik dingen zoals ze zouden
> moeten werken. Ik ga geen bugs van andere fixen.

Dat is een nogal vreemde methode natuurlijk. Jij zou een pagina bouwen op
hoe Google volgens jou zou moeten werken. En vervolgens werkt het niet.....

Ik vind persoonlijk dat ze de a op mijn toetsenbord op de plaats van de i
hadden moeten zetten. Miir dit as wel flank onhindag lezen voor jullae.
Anteresseert maj geen reet... ;-) Gi vinif morgen de p,t,b,u,m, en h ook
omdriiaen.

--
Michiel de Roo.

Online concert agenda voor de stad Utrecht:
http://www.utrecht-live.nl

Daniel Tryba wrote:

> John Bokma <postmaster@castleamber.com> wrote:
>
>>>>"1. Reasons your site may not be included.
>>>>
>>>> * Your pages are dynamically generated. We are able to index
>>>>dynamically generated pages. However, because our web crawler can easily
>>>>overwhelm and crash sites serving dynamic content, we limit the amount
>>>>of dynamic pages we index.
>>>>"
>>>>
>>>>Maar ik vrees dat je het nog steeds niet begrijpt.
>>>
>>>Ik wacht nog steeds op het antwoord hoe google dynamische paginas
>>>herkent. Aan de vorm van de url is het niet te zien.
>>
>>Google neemt (o.a) aan dat een pagina dynamisch is, als de URL een
>>bepaalde vorm heeft.
>
> Aha, bovenstaande tekst van google is dus gewoon foutief opgestelt:
> s/Your pages are dynamically/We assume your pages are dynamically/

Tja, mail ze ff. Zoals al een paar keer geschreven, je kan elke
dynamische pagina zo vermommen dat het niet meer te zien is dat die
dynamisch gemaakt is. Google moet dus op een of andere manier iets
hanteren waardoor een site *wel* geindexeerd kan worden, *maar* zonder
de boel te crashen.

>>/fotos/
>>/fotos/1999/
>>/fotos/1999/vakanties
>>
>>allemaal een index pagina geven met een overzicht is groot als de
>>webbouwer verstand van zaken heeft. En in de praktijk werkt dit
>>inderdaad erg vaak, tenminste ik hack nogal eens URLs :-D.
>
> Mijn ervaring is dat je in heel veel gevallen een mooie melding krijgt
> dat je daar niet mag komen.

niet alle webbouwers hebben verstand van zaken :-D.

>>>>Uiteraard kent elke website bezoeker ook alle belangrijke IP nrs uit
>>>>zijn of haar hoofd.
>>>
>>>Voor websites is dat nauwelijks interessant, virtualhosts zijn namelijk
>>>afhankelijk van een naam.
>>
>>Dat hangt helemaal af van de gebruikte techniek. Bij meer dan 1 website
>>op 1 machine spreekt men van virtual hosting. En je kan meer dan 1 IP
>>nr, dus 1 per virtual host, op 1 machine gebruiken. Meestal moet je daar
>>extra voor betalen, overigens.
>
>
> Rare definitie van virtualhost...

Ja, sorry, dat is een optie van o.a. Apache. Mail ze ff.

> Voorbeeld: mijn firewall heeft 4
> IPv4 nummers, elke netwerkkaart 1, er dus helemaal niets virtueels aan
> meerdere ips op die machine. Wat jij beschrijft ken ik onder de naam "ip
> aliasing" en komt erop neer dat je een netwerkkaart meerdere ipnummers
> geeft, zo heeft de netwerkkaart die de chello uplink regelt 4 publieke IPv6
> nummers waarvan 3 in het zelfde netwerksegment.

Yup, klopt. En met Apache kan je dat onder <VirtualHost> opgeven.
http://httpd.apache.org/docs/vhosts/ip-based.html
" As the term IP-based indicates, the server must have a different IP
address for each IP-based virtual host. This can be achieved by the
machine having several physical network connections, or by use of
virtual interfaces which are supported by most modern operating systems"

Onderaan de pagina staat een voorbeeld.

>>>Dan vraag ik me toch af waarom het subject al sinds het being
>>>"zoekmachines" is... Ik zou wat later opstaan John, het nog veel te
>>>vroeg voor je, _jij_ bent de persoon die begon over de wat gebruikers
>>>zinniger vinden als url.
>>
>>Nee, ik begon over wat zoekmachines als Google zinnig vinden als URL, en
>>dat je een URL *en* Google vriendelijk kan maken (lees: vaker
>>indexeren), *en* ook nog eens vriendelijk voor de bezoeker kan maken.
>
>
> <q src='408ead09$0$196$58c7af7e@news.kabelfoon.nl'>
>
>>Simpel, zet op een voor zoekmachines bereikbare plek URLs neer...
>>Een zoekmachine boeit het niet hoe paginas worden gegenereerd, als een
>>url maar iets zinnigs oplevert.
>
>
> Dat boeit dus wel.
> [http://www.google.com/webmasters/2.html#A1]
> http://johnbokma.com/mexit/2004/04/1...forgoogle.html
> </q>
>
> MAW je herhaalde mijn opmerking nog maar eens dat URL iets zinnigs moet
> opleveren.

Nee, het boeit de zoekmachine wel hoe de pagina gegenereerd wordt, nl,
of het id=1999&k=7 is of /fotos/vakanties/7.html. In beide gevallen is
de URL zinnig, echter pagina's gegenereerd op de 2e manier worden
sneller geindexeerd.

>>>>En van wie is het dus een keuze? Juist! Van de WEBSITE eigenaar. Snap je
>>>>het nu?
>>>
>>>Nee. Als je wilt dat je inhoud gevonden wordt door de monopolist google
>>>heb je geen keuze.
>>
>>Jawel, alleen het indexeren gaat langzamer. De website eigenaar kan zelf
>>het beste beoordelen of Google als een gek een dynamisch deel mag
>>indexeren, of dat dit liever rustig gebeurd.
>
>
> Als googlebot als een gek paginas opvraagt dan dienen de programmeurs
> daarvan naar een heropvoedingscursus te worden gestuurd. Ze zijn nu
> immers aan symptoombestrijding bezig ipv van de oorzaak aan te pakken.

Voor statische pagina's maakt het niet uit (en anders vermom je ze als
dynamisch). Voor dynamische pagina's die middels een complexe berekening
worden aangemaakt natuurlijk wel. Als het aanmaken van 1 pagina 30
seconden duurt, is een request van googlebot elke seconde misschien niet
handig. En bezitters van een statische site willen per keer zo veel
mogelijk pagina's in google hebben, kan niet snel en vaak genoeg gaan.

>>>>"However, because our web crawler can easily overwhelm and crash sites
>>>>serving dynamic content, we limit the amount of dynamic pages we index."
>>>
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>Limiet op aantal, niet op snelheid.
>>
>>Fout! Er staat duidelijk *our web crawler can easily overwhelm and crash
>>sites*. Hoe kan dat? Door het in hoog tempo ophalen van een flink aantal
>>pagina's *per bezoek*. En daarom: "we limit the amount of dynamic pages
>>we index" PER BEZOEK.
>
> het is leuk dat je het woord "per bezoek" erzelf bij verzint.

*zucht* schets ff een scenario waarbij een crawler een site kan doen
crashen door niet in een bezoek (ik definieer een bezoek als een of meer
crawlers halen n pagina's op en verdwijnen dan weer voor een zekere
tijd, als je dit nog niet snapt plak ik wel ff een stukje access_log)

Het KAN niet anders gelezen worden dan per bezoek.

>>Of het werkelijk dynamisch is, is inderdaad niet aan de vorm te zien.
>>Sterker, als het dynamisch is, zijn er massa's truuks om het altijd
>>statisch te presenteren, en omgekeerd. Dus hanteerd Google een ander
>>criteria.
>
> Maar in deze hele thread is dat criteria dan nog niet aan bod
> gekomen... Ik moet mijn vraag dus maar weer herhalen: Hoe herkent google
> dynamische paginas, aan de url is het immers niet te zien.

als er id= in de URL staat, vind Google het dynamisch. Er is nl geen
enkel andere methode om eenduidig onderscheid te maken tussen statisch
en dynamisch. Je kan elke statische pagina als dynamisch vermommen en
vice versa.

>>>En het wordt al helemaal ingewikkeld als je over een tijdje al je urls
>>>op een andere manier moet rewriten of je output moet gaan veranderen om
>>>in de volgende meest gebruikte se te komen.
>>
>>Ja, en stel je voor dat die zoekmachine alle URLs met id= er in gaat
>>uitsluiten. Ben je ook mooi zuur.
>
> Dan heeft die searchengine verdomt weinig content, het aantal zinnig
> zoekresultaten zal dan ook achterblijven met concurenten.

Je geeft zelf het antwoord al op je vraag.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

Daniel Tryba wrote:

> John Bokma <postmaster@castleamber.com> wrote:
>
>>[ dingen die niet werken zoals gedocumenteerd ]
>>
>>
>>>Klopt. En soms is het helaas mogelijk. Je kan of een feature vermijden,
>>>of er om heen hacken en scherp blijven.
>>
>>Dat moet onmogelijk zijn, natuurlijk :-D.
>
>
> Mijn werkgever stelt het helemaal niet op prijs dat ik om fouten van
> externe partijen heen ga hacken, immers heb je op dat moment 2
> problemen:
> -je moet je eigen werknemers tijd laten besteden aan het oplossen van
> het probleem (kost geld)
> -de externe partij heeft slecht werk geleverd en dus niet de afgesproken
> waar het geld.
>
> Bij deze beschrijving komen enkele goed Dilberts in mijn gedachten op.

Als je hardnekkig aan de w3c specs vasthoud, en dus browserbugs negeert,
heb je dus kans dat bezoekers je site niet zien, zoals gewenst, of
helemaal niks zien. Kost geld.

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

Daniel Tryba wrote:

> Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>
>>>>Dat hebben we alleen al in deze thread inmiddels 3 keer uitgelegd. Dit
>>>>begint een beetje saai te worden.
>>>
>>>Schijnbaar krijg je meer artikelen te lezen dan ik op deze nieuwsserver
>>>krijg of dan in googles archief staan.
>>
>>GGHAAaahpff.
>
>
> Tip: eerder naar bed en later opstaan.
>
> Zelfs John heeft het licht al gezien:

Ja, al de hele tijd. Google ziet met id= als dynamisch, zonder id= als
statisch [1]. En aangezien wat Google ziet van belang is voor hoe snel
je pagina's opgehaald worden door googlebot, is het heel verstandig om
je URLs met zorg samen te stellen.

Conclusie: het boeit dus WEL hoe je je URLs kiest, en hoe je je pagina's
genereerd. Doe je het met bla.php?id=1717 of gebruik je fotos/vakantie/

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

Jaap van Wingerde wrote:

> On Tue, 27 Apr 2004 14:59:46 -0500, John Bokma
> <postmaster@castleamber.com> wrote in nl.internet.www.server-side in
> message <408ebbb2$0$195$58c7af7e@news.kabelfoon.nl> with the subject:
> Re: Zoekmachines:
>
>
>>Welke URL is nu mooier voor een gebruiker?
>>
>>/showpage?id=13131547
>>
>>of
>>
>>/fotos/vakanties/1999/srilanka/
>
> Uiteraard is de tweede gemakkelijker voor de gebruiker. Hij kan uit de
> url de inhoud afleiden. Om een hoge plaats in zoekmachines te krijgen,
> is de laatste url ook veel beter. Als je er nu
> foto/vakantie/sri_lanka/ van maakt en er voor zorgt dat in <title> en
> <h1> ook de woorden "foto" "vakantie" "1999" en "Sri Lanka" ben je
> verzekerd van een hoge plaats als iemand zoekt op "foto vakantie 1999
> sri lanka"

Klopt helemaal. Overigens een test in google met
http://www.google.com/search?q=sri+lanka

laat zien dat _ misschien niet echt verplicht is, want op de 4e plaats
zie ik:

www.srilankan.lk/

en op 10:

www.srilankatourism.org

--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced Perl programmer available: http://castleamber.com/

Michiel de Roo <yourlove@welovespam.nl> wrote:
>>>Ja, *zou*. Echter, o.a. Google maakt wel degelijk onderscheid. En hoe
>>>maak jij je websites?
>>
>>
>> Ik maak helemaal geen websites. De laatste is almeer dan 3 jaar geleden.
>
> Heb je wel relevante ervaring met het laten indexeren van pagina's door
> Google dan ?

Ik maak geen content voor searchengines. Al mijn laatste projecten zijn
niet indexeerbaar door enige internetzoekmachine aangezien deze of eisen
dat personen inloggen of dat alleen via een intranet beschikbaar zijn.

>>>Op wat *zou* moeten, of de werkelijkheid?
>>
>> Tot de frustratie van de project manager maakt ik dingen zoals ze zouden
>> moeten werken. Ik ga geen bugs van andere fixen.
>
> Dat is een nogal vreemde methode natuurlijk. Jij zou een pagina bouwen op
> hoe Google volgens jou zou moeten werken.

Niet volgens mij, volgens de documentatie.

> En vervolgens werkt het niet.....

Als de opdracht is dat het voor google geoptimalizeerd moet zijn dan
zoek ik dat wel uit.

Heb je wel eens ervaring opgedaan met diensten die je van externe
partijen betrekt? Je betaald daar goed geld voor, als vervolgens de
documentatie/api niet overeen komt met de werkelijkheid heb je een
probleem.

[knip onzin]

--

Daniel Tryba