Virusscanner tips?
.htaccess verwijzing naar 404.php
https://background-tiles.com/overview/multi-colors.php
https://background-tiles.com/overview/purple.php
of:
https://background-tiles.com/overview/mixed-colors/1128.php
https://background-tiles.com/overview/purple/1045.php
En dit zijn voorbeelden van URL's die niet bestaan maar die google wel probeerd te indexeren:
https://background-tiles.com/overview/grey/black.php
https://background-tiles.com/overview/blue/purple.php
of:
https://background-tiles.com/overview/5031.php
https://background-tiles.com/overview/1120.php
of met slash erachter:
https://background-tiles.com/overview/mixed-colors/1128.php/
https://background-tiles.com/overview/purple/1045.php/
De foute URL's lijken erg op de goede URL's en ik snap in principe ook wel als een pagina niet bestaat en dat ie dan wordt uitgeloten dat dat niet erg is. Maar toch is het vreemd dat die problemen die ineens zijn ontstaan gepaard gaan met het kelderen van de vindbaarheid van mijn website in google zoekresultaten.
Websites moeten wat dat betreft redelijk feilloos zijn anders kunnen zoekmachines hier niet goed doorheen crawlen. Dan is het in zekere zin ook logisch dat als je site kuren vertoont dat deze sowieso niet bovenaan staat in de zoekresultaten. Nu spelen er natuurlijk ook andere zaken maar een correct werkende site is zeker een pré.
Quote:
Dat kan van alles zijn, mogelijk/voornamelijk bots. Waarom zou een bezoeker zelf dingen in gaan typen die afwijken van de reeds aanwezige navigatie en daarmee bewust van de getreden paden af gaan? En als dit dus statistieken of de werking van hulprogramma's vertroebelt dan zul je dus echt een mechanisme moeten hebben die een onjuiste aanroep echt afkeurt. De meest ondubbelzinnig manier om dit te doen is deze rechtstreeks een 404 status geven (door een 404 pagina op te hoesten met bijbehorende 404 status). Als Google die pagina's dan nogmaals inspecteert dan zal deze zien dat de pagina niet (meer) bestaat en zal daar dan verder niet meer naar omkijken. Op deze manier wordt dit probleem ook automatisch opgeschoond. De makkelijkste manier is (wat mij betreft nog steeds) een heel strict beleid: een aanroep is correct of incorrect. Er is geen grijs gebied waarbij een aanroep soms na enige aanpassing wellicht toch juist is.
En dat is waarom ik nou juist graag die slash wil wegwerken.
Ik heb inmiddels naar aanleiding van mijn vorige topic een 404 en een 403 pagina aangemaakt. Nu wil ik alleen nog graag de URL's waar een slash achter zit doorverwijzen naar een 404 pagina of doorverwijzen naar dezelfde URL maar dan zonder slash.
Code (php)
Dit zorgt ervoor dat als er iets achter een scriptnaam staat, dus bijvoorbeeld /test.php/hee/hallo/daar (in dit geval is PATH_INFO dus niet leeg) dat er een 404 header wordt uitgestuurd en er verder geen code meer wordt geladen noch output wordt geproduceerd.
Dit zul je dus wel even moeten testen :).
Waar de "exit;" staat zou je dus ook een summiere 404 pagina kunnen plaatsen of hier een statisch HTML-document kunnen includen.
Nogmaals, je wilt de slash niet wegwerken, je wilt dit soort constructies gewoon niet accepteren :p.
EDIT: dit is nog steeds een blacklist-constructie. Het geeft alleen aan wanneer een aanroep fout is, niet wanneer deze goed is...
Gewijzigd op 18/03/2019 13:21:20 door Thomas van den Heuvel
Quote:
Websites moeten wat dat betreft redelijk feilloos zijn anders kunnen zoekmachines hier niet goed doorheen crawlen. Dan is het in zekere zin ook logisch dat als je site kuren vertoont dat deze sowieso niet bovenaan staat in de zoekresultaten. Nu spelen er natuurlijk ook andere zaken maar een correct werkende site is zeker een pré.
Ik weet zeker dat ik een zeer redelijk feilloze website heb. Daar ben ik van overtuigd. Ik snap ook niet waar google die niet werkende URL's vandaan haalt. Nogmaals mijn website heeft het altijd goed gedaan en ik was lekker aan het stijgen in de zoekresultaten en plots was er die ommekeer.
Toevoeging op 18/03/2019 01:46:41:
Quote:
Hm, misschien een hele simpele hack (die ook wat tests vereist) maar als je een include hebt die in alle pagina's gebruikt wordt zou je het volgende hier in kunnen zetten:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
Dit zorgt ervoor dat als er iets achter een scriptnaam staat, dus bijvoorbeeld /test.php/hee/hallo/daar (in dit geval is PATH_INFO dus niet leeg) dat er een 404 header wordt uitgestuurd en er verder geen code meer wordt geladen noch output wordt geproduceerd.
Dit zul je dus wel even moeten testen :).
Waar de "exit;" staat zou je dus ook een summiere 404 pagina kunnen plaatsen of hier een statisch HTML-document kunnen includen.
Nogmaals, je wilt de slash niet wegwerken, je wilt dit soort constructies gewoon niet accepteren :p.
EDIT: dit is nog steeds een blacklist-constructie. Het geeft alleen aan wanneer een aanroep fout is, niet wanneer deze goed is...
Code (php)
PHP script in nieuw venster Selecteer het PHP script
Code (php)
Dit zorgt ervoor dat als er iets achter een scriptnaam staat, dus bijvoorbeeld /test.php/hee/hallo/daar (in dit geval is PATH_INFO dus niet leeg) dat er een 404 header wordt uitgestuurd en er verder geen code meer wordt geladen noch output wordt geproduceerd.
Dit zul je dus wel even moeten testen :).
Waar de "exit;" staat zou je dus ook een summiere 404 pagina kunnen plaatsen of hier een statisch HTML-document kunnen includen.
Nogmaals, je wilt de slash niet wegwerken, je wilt dit soort constructies gewoon niet accepteren :p.
EDIT: dit is nog steeds een blacklist-constructie. Het geeft alleen aan wanneer een aanroep fout is, niet wanneer deze goed is...
Helaas werkt dit niet. Ik krijg een blanco pagina als ik mijn website bezoek.
Maakt het uit als ik de code in het head gedeelte plaats of is het van belang dat het bovenaan (nog voor het html gedeelte) plaats?
Gewijzigd op 18/03/2019 01:49:52 door Fester Splinter
Het is al laat :p.
Oorspronkelijk voorstel ook aangepast maar zoals aangegeven blijft dit een hack / blacklist.
Heb er nog even over na zitten denken, deze isset() toevoeging zou niet nodig moeten zijn. Geen idee hoe $_SERVER['PATH_INFO'] dan in jouw installatie werkt.
Gewijzigd op 18/03/2019 13:21:01 door Thomas van den Heuvel
Code (php)
1
2
3
2
3
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]
Verder zou ik een canonical URL toevoegen aan elke pagina:
https://support.google.com/webmasters/answer/139066?hl=nl
Quote:
Het kan ook met .htaccess (als je Apache gebruikt):
Hallo Ward,
Het is me al meerdere keren afgeraden om een slash niet weg te werken en dat ik zulke constructies niet zou moeten willen.
Ik weet nu niet zo goed of ik het wel of niet moet gebruiken en welke risico's ik loop.
Quote:
Verder zou ik een canonical URL toevoegen aan elke pagina:
Ik maak gebruik van een sitemap.xml
Hiermee geef ik toch ook aan wat de cannonieke URL's zijn van mijn website?
Je bent in zekere zin ook niets aan het afstraffen want het was in eerste instantie helemaal niet de bedoeling dat deze niet-bestaande pagina's werden aangesproken en vervolgens worden behandeld alsof ze dan toch ergens anders staan? :/
Wat mij betreft moet je niet cateren voor wat niet geldig is, maar voor wat wél geldig is (en dus ook niet een brug proberen te slaan tussen deze twee).
Laat verkeerde requests gewoon fout gaan.
Gewijzigd op 18/03/2019 15:32:36 door Thomas van den Heuvel
Thomas van den Heuvel op 18/03/2019 15:31:27:
Maar de fout(e aanroep) werd met opzet gecreëerd (topicstarter constateert dat als je pagina's aanroept met een slash dat zijn site uit elkaar valt)? En vervolgens ga je deze fout ook zelf rechtbuigen?
Ik las iets anders:
Mark Coenie op 18/03/2019 01:34:01:
Ik weet zeker dat ik een zeer redelijk feilloze website heb. Daar ben ik van overtuigd. Ik snap ook niet waar google die niet werkende URL's vandaan haalt. Nogmaals mijn website heeft het altijd goed gedaan en ik was lekker aan het stijgen in de zoekresultaten en plots was er die ommekeer.
Als je niet weet wat er precies aan de hand is, wat ben je dan aan het oplossen/repareren?
Mogelijk was er ten tijde van de dip iets compleet anders aan de hand?
Gewijzigd op 18/03/2019 16:22:17 door Thomas van den Heuvel
Quote:
Als je niet weet wat er precies aan de hand is, wat ben je dan aan het oplossen/repareren?
Wat ar echt aan de hand is, ik heb echt geen idee.
Ik probeer nu zoveel mogelijk op te lossen op basis van wat ik wel weet.
Ik heb kort geleden de google advertenties aangepast, omdat er op de oude advertenties niet geklikt werd. Maar ik hou mij wel aan de richtlijnen voor het plaatsen van de advertenties.
Verder ben ik er van de week achter gekomen dat het onbeveiligde (http) gedeelte gewoon bereikbaar was voor bezoekers zonder dat de bezoeker doorgestuurd werd naar het beveiligde (https) gedeelte.Dit was een fout van de hostingprovider en is inmiddels opgelost. Het laatste probleem liep waarschijnlijk al veel langer.