Aangemaakte reacties
-
Berichten
-
Het lijkt me nu wel duidelijk: het feit dat Dierenpark Emmen zélf (via de meta-refresh, inderdaad) meent dat de ‘China Festival of lights’ – website getoond moet worden als men naar hun website gaat, is voldoende reden voor Google om de laatste te tonen. Dat is dus mooi gedaan van Google.
Wat PageRank betreft begrijp ik de stelling van GoalGorilla niet helemaal. Indien een website hoger scoort dan de andere kan je niet zeggen dat de PageRank van de ene hoger is dan de andere. PageRank wordt (eens in de zoveel tijd) berekend op basis van de verwijzingen naar de betreffende pagina (d.w.z. de PageRank’s van die verwijzende pagina’s en het aantal verwijzingen van de verwijzende pagina’s). Daar komt voor iedere pagina dus een getal uitrollen. Daar dit een nogal onhandig getal is, wordt het afgebeeld (via een logaritmische formule) op een getal tussen 0 en 10. Dit is de Toolbar PageRank.
PageRank en Toolbar PageRank zijn dus in de kern dezelfde.
Pagerank en Trustrank uitgelegd | SEO guruIk kom er twee keer per maand ongeveer en ook IN dierenpark emmen heb je het idee dat er meer festival is dan dierenpark.
Misschien is Matt Cutts ook in Dierenpark Emmen geweest? :rolleyes:
En als we nog een paar keer ‘dierenpark emmen’ in onze discusie noemen, staan wij waarschijnlijk straks nr1…. Mooi in ieder geval dat de naam van de thread ook netjes begint met ‘dierenpark emmen’.
Ja, het zou leuk zijn als we daar iets zinnigs over konden zeggen. Probleem is dat je daar moeilijk een absoluut getal aan kan hangen, omdat het van zoveel verschillende factoren afhankelijk is. Bijvoorbeeld: van waaruit vindt de test plaats? Hoe is de kwaliteit van de verbinding op het moment van testen? Hoe zwaar wordt de server op dat moment toevallig belast voor andere websites? Etc., etc.
Daarom is het getal wat YSlow geeft (achter het tabblad ‘Statistics’) misschien nog wel het meest objectief, namelijk het aantal ‘http requests’ en de ’total weight’ (kb), bij een empty cache (want Google komt langs met een lege cache).
In het geval van de seoguru-homepage zijn dat 28 requests bij een weight van 128.1k.
De homepage van dit forum komt uit op 32 requests bij een weight van 141.3kMaar als er een hele langzame of drukke server achter hangt, dan hebben we aan deze getallen niet genoeg. Mooiste zou zijn als er vanaf 1 punt gemeten kon worden. Alexa heeft wel zo’n service, alwaar ik voor mijn website lees:
Average Load Time for Seoguru.nl
Very Fast (0.836 Seconds), 88% of sites are slower.Maar hoe representatief deze meting is weet ik niet.
Tot slot wil ik nog even verwijzen naar de volgende Google-uithoek waar van alles te vinden is over het versnellen van websites: Let's make the web faster – Google Code
Interessant.
Ik zie dat ytimg een domein is van youtube via welke -naar ik aanneem- de images uitgepakt kunnen worden uit dat ene .png bestand.
Maar hoe kunnen wij dat met onze website doen? Het zou bijvoorbeeld mooi zijn als je door een argument mee te geven aan de .png de specifieke image eruit kan halen. Maar dan moet het .png-formaat dat wel ondersteunen, en ik heb geen idee of dat zo is. M.a.w. wat is een goede manier?
Helder, dank.
Ik neem aan dat er na bandbreedte-optimalisatie twee requests nodig zijn, één voor de (samengevoegde) .css en één voor de (samengevoegde) .js?
Even wat vraagjes, Taco.
1. Hoezo moeten er minder requests naar de server als de bestanden zijn gecomprimeerd? Ik kan alleen zien dat gecomprimeerde bestanden sneller kunnen worden opgehaald omdat ze kleiner zijn.
2. En waar vindt het decompressen plaats? In de browser?Ja, goed dat we deze discussie een keer voeren, dank ook voor de goede verwijzingen. Weliswaar zojuist teruggekeerd van een wortelkanaalbehandeling, en nog een beetje beduusd, hierbij mijn reactie.
In letterlijke zin lijkt keyword-density tegenwoordig geen onderdeel meer uit te maken van de zoekmachine-algoritmes die de rankings bepalen. Wellicht heeft het uberhaupt nooit onderdeel uitgemaakt van de algoritmes, zelfs niet in de 90’s. Zo begrijp ik de artikelen van GoalGorilla. Het is inderdaad een té eenvoudige maat om iets zinnigs te zeggen over een tekst. Waarschijnlijk daarom dat zoekmachines zo veel meer waarde hechten aan de ankerteksten in de verwijzingen naar de verschillende pagina’s. Keyword density kan dus worden geschrapt uit het seo jargon, en daarmee uit mijn handleiding en ebook …
Dit gezegd hebbende moet vermeld worden, en de betreffende artikelen zijn hier heel duidelijk in, dat de keyword frequentie wel degelijk een rol speelt. Niet zo expliciet in de vorm van een dichtheids-getal, maar een complexer getal, namelijk de ’term weight’, die bepaald wordt op basis van een ‘local weight’ en de ‘global weight’. Nu blijkt die local weight berekend te worden uit de keyword frequentie op een pagina. (De global weight is overigens het percentage van het aantal geindexeerde pagina’s binnen de site dat betreffend keyword bevat.)
Ik kan dit niet anders lezen dan dat de pagina’s van de site bij voorkeur wel degelijk betreffende keywords dienen te bevatten. Ik neem daarbij aan dat er een minimum is, en een ook een maximum. Als een pagina namelijk is volgepropt met een bepaald keyword kan dat een indicatie zijn voor spam. Als daarentegen een keyword nauwelijks op een pagina voorkomt kan je je afvragen of je die pagina wilt lezen als je op zoek bent naar dat keyword. Ik ben van mening dat je dit minimum en maximum, ter indicatie, best mag uitdrukken in een dichtheids-getal.
In mijn handleiding noem ik een minimum van 1.5% en een maximum van 15%. Dit is misschien nog steeds wel een aardige maat. Maar, natuurlijk, het verhogen van de dichtheid heeft geen verbeterde rankings tot gevolg, noch het omgekeerde is het geval. Het zijn uitersten of signalen op basis waarvan een contentbeheerder actie kan ondernemen. Keyword density is echter geen factor van belang in de zoekmachine algoritmes.
Ik zou kopieren-in-soest.nl nemen, puur voor de leesbaarheid. Ik verwacht geen verschil in SEO-kwaliteit tussen de drie.
Bij voorkeur scoor ik zowel in de lokale (bedrijven in google maps) als in de reguliere organische zoekresultaten. Ik zou de plaatsnaam daarom niet weglaten uit de tekst. Waarom overweeg je dit toch?
Als het goed is, is het nu mogelijk voor alle geregistreerden een url in de handtekening te plaatsen. Ik ga er wel voor waken dat dit netjes gebeurt.
Als je op ‘menuknop’ gevonden wilt worden is de anchor ‘menuknop’ beter, maar ik neem aan dat je op URLs doelt. En dan lijkt de vraag veel op de vraag die je hiervoor hebt gesteld. Mijn antwoord: kies http://www.domeinnaam.nl/ voor de interne verwijzingen naar je homepage en 301-redirect alle andere varianten naar die URL om afwijkende inlinks om te buigen naar de juiste. Hierdoor komt alle PageRank bij die ene, juiste, URL terecht.
sitemap.xml voegt niet iets toe, behalve dat e.e.a. sneller wordt geindexeerd, maar dat lijkt me niet direct van belang. Als je een goede hierarchie weet aan te brengen in je zoekopdrachten en je die laat terugkomen in je directorystructuur is dat goed. Dan zou je homepage de top van de hierarchie worden.
Als je bijvoorbeeld een website over vervoersmiddelen hebt en men bij jou bijvoorbeeld zoekt op ‘fiets’, ‘auto’, ‘gazelle’ en ‘audi x290′, kan je vanaf de homepage linken naar auto’s zowel als fietsen en vanuit auto’s weer door naar audi x290′, etc. De url’s worden dan /autos/, met een link naar /autos/audi-x290. En neem dan breadcrumbs op de pagina’s op. Het liefst zou je zo’n hierarchie geautomatiseerd opstellen.
Het is geen spam, je laat immers aan Google niet iets anders zien dan je aan je gebruikers laat zien. Ik heb redelijk recent een verhaal vernomen van een bedrijf die precies hetzelfde heeft gedaan en daar zeer goede resultaten mee bereikte. Als de pagina’s verder geen of weinig content hebben is het aan Google om ze niet hoog te laten waarderen. Het probleem ligt dus bij hen en niet bij jou.
O ja, en wat betreft het onderhavige onderwerp vind ik Taco’s antwoord eigenlijk beter dan die van mezelf. Het lijkt me inderdaad onwaarschijnlijk dat de positie van de tekst in de html nog een signifikante rol speelt, precies omdat er op dat punt zo veel gerommeld kan worden.
Wat steeds belangrijker zal worden zijn de semantische aanduidingen die aan de teksten kunnen worden meegegeven, via bv standaard id’s en classnames. Dan kan ook bij een menu worden aangegeven (dus onafhankelijk van de plaats in de code) dat het een menu betreft (bijvoorbeeld id=menu), waar de navigatie staat (bijvoorbeeld id=navbar) en wat nu precies de content is (bijvoorbeeld id=content of id=main). Zo ver lijkt het helaas nog niet, maar het “semantische web” zal er komen, hetgeen de plaats van de verschillende pagina-onderdelen in de code helemaal onbelangrijk zal maken.
Wat in mijn optiek wel zal blijven is het belang van de positie van de tekst in de content zelf. Een eerste (en wellicht ook laatste) alinea zal belangrijker blijven dan bijvoorbeeld een 12e alinea.
Als het goed is kan je in je signature (bij je gebruikersinstellingen) ook linkjes aangeven. Ik heb het nu ook toegevoegd, dus er zou hieronder nu een gelinkte signature moeten staan… Overigens zie ik dat mvdgeijn zijn link hard in het bericht heeft geplaatst, m.a.w. dat die niet automatisch vanuit zijn signature is toegevoegd.
