John Mueller, a Google munkatársa válaszolt egy kérdésre a Redditen, amely egy belső weboldalra mutató hivatkozásra vonatkozik, amelyet a Squarespace, egy zárt forráskódú platform automatikusan hozott létre. A weblapra mutató hivatkozást a robots.txt is blokkolta a feltérképezésben, ami nyilvánvalóan nem szolgált a Redditor kliensének. A kérdést feltevő személy frusztrált volt, mert a CMS nem engedélyezte a hivatkozás eltávolításához szükséges szerkesztést, és aggódott a rosszindulatú belső hivatkozás által okozott SEO problémák miatt.
Kérdés az automatikusan generált belső URL-ről
Egy keresőoptimalizáló tett közzé erről a problémáról a Redditen, miközben megpróbálta kijavítani az ügyfele technikai problémáit, beleértve egy olyan weboldalra mutató hivatkozás eltávolítását, amelyet az ügyfél nem szándékosan hozott létre, és amelyet a platform automatikusan generált, amely nem tette lehetővé a hivatkozás eltávolításához szükséges szerkesztést.
Bár az URL-t a robots.txt blokkolta, a Screaming Frog továbbra is észlelt a weboldalra mutató belső linkeket, ami aggodalmát fejezte ki amiatt, hogy a Google képes lesz megtalálni a weboldalra mutató hivatkozásokat.
Megkérdezték:
„Szia majd…
Megoldok néhány kiemelt problémát az ügyfelem számára, és van még egy utolsó. Van egy belső URL, amelyet a robots txt blokkol. Az ügyfelem a Squarespace-t használja. A blokkolt oldalt nem a kliens hozta létre, de úgy tűnik, hogy a squarespace által kiváltott oldal a következő:
https://domain/categories/=59487a4cd1758e7669102174
Az érdekes, hogy a Screaming Frog segítségével megtalálom az oldalra mutató linkeket, de ez egy a href-ben van elrejtve. A fejlesztői eszközökön keresztül megtaláltam, de fogalmam sincs, hogyan kell törölni a hivatkozást, mivel az SS nem ad hozzáférést a háttérrendszerhez.
Mi a fene folyik itt, és hogyan oldjam meg?”
A látszólag véletlenszerű, platform által generált linkek nem befolyásolják a SEO-t
John Mueller, a Google munkatársa azt válaszolta, hogy az URL-cím és a linkek, amelyekre mutatnak, nem jelentenek problémát a keresés láthatóságában. A linkek figyelmen kívül hagyását javasolta.
Mueller elmagyarázta:
„Nem igazán számít. Én figyelmen kívül hagynám. Egyáltalán nincs hatással a keresésre / SEO-ra.
Egyes platformokon csak ilyen hivatkozások vannak, ha a hivatkozás mögött nincs semmi, amit indexelni szeretne, akkor nincs mit tennie. (És lehet, hogy nem tehetsz semmit, ha hostolt platformon vagy.)”
Mik azok a Squarespace linkek valójában
A hosztolt CMS-platformok vezérlik az alapul szolgáló sablonokat, útválasztási rendszereket és a JavaScript-megjelenítési folyamatot. Ez az oka annak, hogy a Squarespace-ben található URL-ek, például a felhasználó által megjelölt URL-ek, nem szerkeszthetők, mert a webhely belső architektúrájának részét képezik.
Ez az URL valószínűleg a Squarespace belső URL-azonosítója az adatbázisában. Tehát ahelyett, hogy ilyen módon hivatkozna egy URL-re, kategória=cipők, a belső adatbázis-azonosítóval hivatkozik rá a következő módon:
59487a4cd1758e7669102174
A ?format=json-pretty trükk
A Squarespace által üzemeltetett webhelyek mögöttes adatbázis-azonosítóinak megtekintéséhez egyszerűen adja hozzá a ?format=json-pretty karakterláncot bármely URL végéhez, és a Squarespace leállítja a vizuális weboldal megjelenítését, és kiadja az adott weboldal JSON-formátumú kódját. Ez egy trükk, amelyet a Squarespace fejlesztői használnak.
Képernyőkép a ?format=json-pretty kimenetről
Ennek a módszernek van értelme, mert a CMS-rendszer egyetlen belső kanonikus azonosítót tud használni a kategória URL-jéhez, és a felhasználók tetszőlegesre módosíthatják azt. Tehát függetlenül attól, hogy a felhasználó milyen kategórianevet választ, a belső adatbázis-azonosító változatlan marad, még ha meggondolja magát.
Ezen információk ismerete nélkül egy kívülállónak úgy tűnhet, mint egy zárt forráskódú CMS-nek, amely korlátozza a felhasználó szabadságát, amit a WordPress látszólag nem tesz meg. A valóság azonban az, hogy a Squarespace abszolút szabadságot biztosít a felhasználó számára, hogy elnevezze a kategóriáit, bármit is választanak, és ezek a nem szerkeszthető URL-ek egy célt szolgálnak, hogy ez megtörténjen.
A WordPress is hasonlót csinál a belső azonosítókkal, csak jobban el van rejtve. A WordPress a term_id attribútumot használja a kategóriákhoz és címkékhez, a post_id értéket pedig a bejegyzésekhez, termékekhez, oldalakhoz és mellékletekhez. Néha láthatja a term_id és post_id a nyers HTML-ben, amelyet a WordPress generál, amikor belenéz a forráskódba, és csakúgy, mint a ma már nem titokzatos Squarespace URL-ek esetében, ezt sem kell szerkeszteni vagy eltávolítani SEO célból.
A technikai SEO auditok, beleértve a Screaming Frog segítségével végzett feltérképezéseket is, feltárhatnak néhány furcsán kinéző műterméket, amelyeknek valójában ott kellene lenniük. A CMS működésének ismerete segít a keresőoptimalizálónak és a webhelytulajdonosnak megérteni, hogy valami furcsa dolog valóban furcsa-e, és hogy az 100%-ban normális-e. Különösen akkor, ha olyan CMS-sel dolgozik, amelyet nem ismer jól, fontos, hogy ne végezzen SEO célú változtatásokat, mielőtt megismerné a mögöttes CMS működését. Sokszor, amit nem értünk jól, az valójában valami, amit biztonságosan magára hagyhat, ahogy azt a Google munkatársa, John Mueller javasolta.
Ami a Screaming Frog beállítását illeti a Squarespace webhelyek feltérképezésére, hasznos lehet beállítani úgy, hogy engedelmeskedjen a Robots.txt fájlnak, vagy akár manuálisan állítsa be, hogy kizárja bizonyos oldalak feltérképezését.
