Pse blogu im Angular nuk është i indeksuar nga Google (dhe si e rregullova)

Hyrje: Kur Google thjesht injoron blogun tuaj

Disa javë më parë u bëra i vetëdijshëm për një problem të bezdisshëm: artikujt e publikuar në të njëjtin blog nuk po shfaqeshin në Google. Ata nuk ishin të pozicionuar keq, nuk patën pak trafik - thjesht nuk u indeksuan. Me hapjen e Google Search Console, situata ishte e qartë: nga 32 URL-të e dërguara në hartën e faqes, vetëm 4 u indeksuan (shtëpia, listimi i blogut, projektet, kontaktet). Zero artikuj.

Ajo që vijon është rruga aktuale që kam marrë për të diagnostikuar dhe zgjidhur problemin, nga dyshimi i parë teknik deri te shkaku i fshehur që askush nuk e kontrollon kurrë: përmbajtjen e kopjuar. Nëse drejtoni një blog teknik, veçanërisht në një aplikacion Angular me paraqitje nga ana e serverit, ndoshta do të njihni të paktën një nga këto probleme.

Dyshimi i parë: faqet e paraqitura në anën e klientit në vend të serverit

Kontrolli i parë në këto raste është gjithmonë i njëjtë: çfarë sheh vërtet Googlebot kur viziton një faqe? Në një aplikacion Angular me SSR, nëse interpretimi nga ana e serverit nuk funksionon siç pritej, zvarritësi merr vetëm guaskën e zbrazët HTML - pa specifik, asnjë përshkrim meta, asnjë përmbajtje tekstuale aktuale, të gjitha të mbushura nëpërmjet JavaScript pas bootstraps Angular.

Në rastin tim, shkaku ishte në angular.json: projekti ishte ende duke përdorur flamurin boolean të trashëguar "prerender": true në vend të "outputMode" më të ri: "server". Me flamurin Boolean, Angular prezanton vetëm rrugët statike dhe injoron në heshtje getPrerenderParams() - funksioni që zgjeron rrugët dinamike si /blog/:slug duke marrë të gjitha slugs të publikuara nga backend. Rezultati: të gjitha faqet statike (shtëpia, projektet, kontaktet) u parapërgatitën saktë, por çdo postim i vetëm i blogut mbeti një faqe e pastër nga ana e klientit.

// angular.json — prima (sbagliato)
"prerender": true

// angular.json — dopo (corretto)
"outputMode": "server"

Me outputMode: "server", Angular në fakt thërret getPrerenderParams() për çdo rrugë dinamike të konfiguruar në app.routes.server.ts, e cila në rastin tim kërkon GET /blog/posts në fund dhe gjeneron një faqe statike për çdo slug të postuar. Pas rregullimit, ndërtimi më në fund prodhoi çdo artikull si HTML të vërtetë, me titullin, përshkrimin meta dhe artikullin JSON-LD gati në bajtin e parë.

Defekti i fshehur i Apache: 301 ridrejtime në çdo faqe të paravendosur

Pas rregullimit të paraqitjes paraprake, një kontroll me një kaçurrelë të thjeshtë -I (jo një shfletues, i cili ndjek ridrejtimet në mënyrë transparente dhe fsheh problemin) zbuloi një të metë të dytë: çdo faqe e paraqitur paraprakisht u përgjigj me 301 Zhvendosur në mënyrë të përhershme drejt së njëjtës URL me vijën vijuese të shtuar.

Shkaku është sjellja e parazgjedhur e Apache-së, mod_dir: kur një kërkesë përputhet me një direktori reale në disk (dhe kjo është pikërisht ajo që krijon prerendering: /blog/article-name/index.html), Apache ridrejtohet automatikisht duke shtuar vijën e pjerrët pasuese, përpara se rregullat mod_rewrite në .htaccess të mund të ndërhyjnë. Përmbajtja pas ridrejtimit ishte e saktë, por URL-ja kanonike e deklaruar në çdo faqe (pa një vijë të pjerrët pasuese, në përputhje me hartën e faqes) nuk ktheu kurrë një 200 të drejtpërdrejtë – zvarritësit merrnin gjithmonë një URL të ndryshme nga ajo e shënuar si kanonike.

<IfModule mod_dir.c>
  DirectorySlash Off
</IfModule>

RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{REQUEST_FILENAME}/index.html -f
RewriteRule ^(.*)$ $1/index.html [L]

Duke çaktivizuar shkurtimin automatik dhe duke shtuar një rregull të qartë që shërben index.html drejtpërdrejt në URL-në e paprerë, çdo faqe e paravendosur filloi të përgjigjet me 200 në URL-në e saktë kanonike.

Harta e faqes statike kundrejt sajtit të krijuar nga përmbajtja reale

Një problem i tretë, më banal, por po aq bllokues: harta e faqes përmbante vetëm faqen e listimit / blogut, jo artikujt individualë. Çdo postim i ri i publikuar mbeti i padukshëm për Google derisa të zbulohej nëpërmjet lidhjeve të brendshme – një proces i ngadaltë dhe aspak i garantuar.

Zgjidhja ishte transformimi i skriptit të gjenerimit të hartës së sitit nga një listë statike rrugësh në një funksion që kërkon prapavijën për çdo postim të publikuar:

async function fetchBlogRoutes() {
  const res = await fetch(`${API_BASE_URL}/blog/posts?page=1&limit=50`);
  const { data, meta } = await res.json();
  const posts = [...data];
  for (let page = 2; page <= meta.totalPages; page++) {
    const r = await fetch(`${API_BASE_URL}/blog/posts?page=${page}&limit=50`);
    const j = await r.json();
    posts.push(...j.data);
  }
  return posts.map(p => ({ loc: `/blog/${p.slug}`, lastmod: p.updatedAt }));
}

I njëjti skrip tani funksionon edhe si GitHub Action, çdo natë dhe me çdo shtytje, kështu që çdo artikull i ri i botuar hyn automatikisht në hartën e faqes pa ndërhyrje manuale.

Shkaku më tinëzar: përmbajtja e kopjuar

Pas gjithë këtyre rregullimeve teknike, situata u përmirësua, por nuk u zgjidh: shumica e artikujve mbetën në gjendjen "Zbuluar, aktualisht jo të indeksuar" - Google i njihte URL-të nga harta e faqes, por ende nuk i kishte konsideruar ato të përshtatshme sa duhet për të indeksuar. Duke analizuar listën artikull për artikull, gjeta dy postime të publikuara brenda 28 sekondave nga njëri-tjetri, në të njëjtën temë, me tituj pothuajse të padallueshëm dhe përmbajtje pothuajse të mbivendosur - ndoshta një postim i dyfishtë aksidental nga paneli i redaktuesit.

Përmbajtja e kopjuar nuk bllokon indeksimin e një faqeje të vetme: është një sinjal i cilësisë i vlerësuar në nivelin e të gjithë domenit. Në një sajt të ri, me shumë pak autoritet të jashtëm, disa postime të kopjuara mund të jenë të mjaftueshme për ta bërë Google më të kujdesshëm ndaj përmbajtjes plotësisht origjinale në të njëjtin domen. Fshiva versionin me më pak shikime dhe rigjenerova hartën e faqes: është ndoshta ndërhyrja e vetme me ndikimin më të madh në indeksimin e përgjithshëm të faqes.

Si të lexoni në të vërtetë raportin e "Indeksimit të faqeve" të Konsolës së Kërkimit

Raporti i Google Search Console grupon faqet e paindeksuara sipas arsyes dhe secila etiketë kërkon një veprim të ndryshëm:

I zbuluar, aktualisht i pa indeksuar: Google e njeh URL-në (zakonisht nga harta e faqes) por nuk e ka zvarritur ende. Është çështje kohe dhe buxheti zvarritës, jo një gabim për t'u rregulluar.
Zvarritur, aktualisht i pa indeksuar: Google e vizitoi faqen, por zgjodhi të mos e indeksonte, shpesh për shkak të përmbajtjes që konsiderohet të jetë me vlerë të ulët ose të kopjuar.
Faqe alternative me etiketën e duhur kanonike: normale për versionet e përkthyera të së njëjtës përmbajtje që drejtojnë saktë versionin kryesor - jo një gabim.
Gabim i ridrejtimit: Kushtojini vëmendje datës së skanimit të fundit. Nëse defekti është rregulluar pas asaj date, raporti thjesht tregon të dhëna të vjetruara: thjesht kontrolloni me curl -I që URL-ja të përgjigjet 200 sot, më pas përdorni "Validoje rregullimin" për të detyruar një kontroll të ri.

Lista kontrolluese praktike

Kontrolloni me curl -I (jo me shfletuesin) që secila faqe i përgjigjet drejtpërdrejt URL-së kanonike, pa ridrejtime të fshehura.
Kontrolloni që përmbajtja e marrë nga një zvarritës të jetë identike me atë të një shfletuesi të vërtetë: curl -Një "Googlebot" duhet të kthejë HTML të plotë, jo një guaskë të zbrazët që pret JavaScript.
Gjeneroni hartën e faqes në mënyrë dinamike nga përmbajtja e publikuar, jo nga një listë statike rrugësh.
Kërkoni tituj ose tema pothuajse identike në postimet tuaja – përmbajtja e kopjuar është një problem domeni, jo një faqe e vetme.
Përdorni "Kërkesë Indeksimin" në Search Console në postimet më të reja në vend që të prisni për zvarritje natyrale, e cila mund të zgjasë javë të tëra në një domen të ri.

Afatet kohore realiste

Në një domen të ri, me pak shenja autoriteti të jashtëm, është normale që indeksimi i parë të zgjasë nga disa ditë (me kërkesë manuale) deri në disa javë (nëpërmjet zvarritjes natyrale). Ajo që ka vërtet rëndësi është eliminimi i pengesave teknike dhe të cilësisë së përmbajtjes: pasi të hiqen, është thjesht një çështje që t'i jepet Google kohë për të shqyrtuar dhe besuar domenin.