Ano ang nangyayari kapag mali ang canonical tags

Ang canonical tag ay hindi pambura ng duplicate content

Sinasabi ng canonical tag sa search engines kung aling URL ang mas gusto mo kapag may ilang URL na may pareho, o halos magkaparehong, content. Ganito ang karaniwang HTML version:

<link rel="canonical" href="https://example.com/preferred-page/">

Mayroon ding HTTP header version, na kadalasang kapaki-pakinabang para sa non-HTML files gaya ng PDFs:

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

Mukha itong sapat na simple. Nagsisimula ang problema kapag itinuturing ng mga team ang canonical tags bilang ligtas na paraan para ayusin ang anumang magulo: faceted navigation, tracking parameters, print pages, halos duplicate na product pages, pagination, staging URLs, at lumang campaign pages.

Hindi delete button ang canonical tags. Hindi sila redirect. Hindi sila kapalit ng information architecture. At hindi garantisadong susundin sila.

Ginagamit ng search engines ang canonicals bilang malalakas na hint. Inihahambing nila ang canonical tag sa iba pang signal: redirects, internal links, sitemap URLs, hreflang annotations, content similarity, HTTP status codes, at ang mga URL na aktuwal na nararating ng users at crawlers. Kung nagkakasalungatan ang mga signal na iyon, maaaring balewalain ng search engine ang canonical mo o pumili ng ibang canonical URL nang buo.

Kaya nakakalito kapag mali ang canonicals. Mukhang tama ang markup sa browser, pero maling page ang lumalabas sa search results — o nawawala ang tamang page.

Ano ang nangyayari kapag nakaturo ang canonical sa maling URL

Kapag nakakakita ang search engine ng duplicate o halos duplicate na URLs, karaniwan nitong pinapangkat ang mga ito sa isang cluster at pumipili ng isang URL bilang canonical. Ang napiling canonical ang version na pinakamalamang na ma-index at maipakita sa search results. Maaaring pagsamahin ang mga signal mula sa mga duplicate papunta sa napiling URL na iyon.

Kung nakaturo ang canonical tag mo sa maling page, ilang bagay ang maaaring mangyari.

1. Nai-index ang maling URL

Ipagpalagay na mayroon kang dalawang URL:

• /mens-running-shoes/
• /sale/mens-running-shoes/

Kung ang sale page ay nagka-canonical sa main category page, maaaring ayos lang iyon kung halos magkapareho ang content at ang sale URL ay filtered version lang. Pero kung may natatanging copy, natatanging products, at sariling search demand ang sale page, maaaring pigilan ito ng canonical.

Maaaring ma-crawl pa rin ang page. Maaaring accessible pa rin ito sa users. Pero maaaring magpasya ang search engines na huwag itong i-index nang hiwalay dahil sinabi mong ibang URL ang preferred version.

Ito ang pinakakaraniwang canonical failure: hindi isang dramatikong technical outage, kundi isang tahimik na pagkawala mula sa index.

2. Napagsasama ang ranking signals sa maling lugar

Madalas gamitin ang canonicals para pagsamahin ang mga signal gaya ng links at duplicate content variants. Kapaki-pakinabang iyon kapag tunay na magkatumbas ang mga duplicate. Delikado ito kapag hindi.

Kung may tracking URLs ang isang blog article gaya ng:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

Makatuwirang i-canonicalize ang dalawa sa /guide-to-canonical-tags/.

Pero kung ang Spanish version, printable version na may dagdag na content, o product variant na may ibang intent ay nakaturo sa parehong canonical, maaaring pinagsasama mo ang mga signal na dapat manatiling magkahiwalay. Ang resulta ay maaaring mas mahinang relevance para sa lahat ng ito.

Tungkol sa equivalence ang canonical tags. Kung ang dalawang page ay tumutugon sa magkaibang search intents, malamang na hindi sila dapat mag-canonicalize sa isa’t isa.

3. Binabalewala ng search engines ang tag

Hindi command ang canonical. Kung ang canonical target ay nagre-redirect, nagbabalik ng 404, blocked, may noindex, o may napakaibang content, maaaring balewalain ito ng search engines.

Mabuti iyon sa isang banda: hindi laging sinisira ng bad canonical ang indexing. Pero nangangahulugan din ito na hindi mo dapat ipagpalagay na ginagawa ng tag ang iniisip mo. Maaaring magdeklara ang page ng isang canonical habang ibang canonical ang pinipili ng Google.

Lalo itong karaniwan kapag hindi nagtutugma ang internal links, sitemaps, at canonicals. Kung bawat internal link ay nakaturo sa /product, nakalista sa sitemap mo ang /product/, at ang canonical mo ay nakaturo sa https://www.example.com/product?ref=main, nakagawa ka ng maliit na pagtatalo sa pagitan ng sarili mong signals.

Mahusay ang search engines sa paglutas ng pagtatalong iyon. Hindi lang palaging ayon sa intensiyon mo ang paraan ng paglutas nila.

4. Nagiging hindi kinakailangang mahirap ang pag-debug

Bihirang pumalya nang maingay ang bad canonicals. Gumagawa sila ng mga sintomas na mukhang ibang SEO problems:

• “Discovered, currently not indexed” o katumbas na indexing limbo
• Maling URL na nagra-rank para sa isang query
• Parameter URLs na lumalabas sa reports
• Category pages na hindi lumalabas kahit crawlable
• International pages na naisisingit sa maling language version
• Bagong templates na inilulunsad na mas kaunti ang indexed pages kaysa inaasahan

Kaya dapat isama sa canonical debugging ang raw HTML, rendered HTML, HTTP headers, redirects, at sitemap entries. Kung iniimbestigahan mo na ang redirect chains o mismatched headers, pareho ang mga kaugaliang kailangan; ang praktikal na HTTP inspection workflow gaya ng nasa aming guide sa pag-debug ng redirects at HTTP headers in production ay karaniwang mas mabilis makakahuli ng canonical contradictions kaysa pagtitig sa isang CMS field.

Ang pinakamagastos na canonical mistakes

Pagka-canonicalize ng lahat sa homepage

Nangyayari pa rin ito. Naiiwang blanko ang isang template field, bumabalik ang plugin sa site root, at biglang daan-daang page ang nagdedeklara sa homepage bilang canonical.

Maaaring balewalain ito ng search engines dahil malinaw na iba ang content. Pero kung sapat na magulo ang signals, maaaring ma-drop o maling ma-cluster ang ilang page. Sa minimum, nagpapadala ka ng walang silbi at salungat na hint sa bawat page.

Halos hindi kailanman canonical ng internal page ang homepage.

Pagka-canonicalize ng paginated pages sa page one

Sa mahabang panahon, ini-canonicalize ng ilang site ang /category/page/2/, /page/3/, at iba pa pabalik sa page one. Ang intensiyon ay iwasan ang duplicate category pages.

Ang problema ay hindi duplicate ang paginated pages. May iba-iba silang items at tumutulong silang madiskubre ng crawlers ang mas malalim na content. Ang pag-canonicalize sa lahat ng ito sa page one ay maaaring magpababa ng tsansang lubusang maproseso ng search engines ang mga susunod na page.

Karaniwan, dapat may self-referencing canonicals ang paginated pages maliban kung may partikular na dahilan para pagsamahin.

Pagka-canonicalize ng filtered pages nang hindi sinusuri ang search intent

Lumilikha ng mahihirap na pagpili ang faceted navigation. Basura ang ilang filtered URLs:

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

Maaaring mahalagang landing pages ang iba:

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

Madalas na nabubura ng blanket canonical rules ang kapaki-pakinabang na search pages kasama ng walang silbing parameter noise. Bago i-canonicalize ang filtered pages, itanong kung may stable content, internal links, search demand, at natatanging pangangailangan ng user ang filtered page.

Kung oo ang sagot, maaaring karapat-dapat itong maging indexable na may self-referencing canonical.

Pagturo ng canonicals sa redirected o blocked URLs

Dapat malinis, indexable, at nagbabalik ng 200 OK ang canonical target. Huwag ituro ang canonicals sa URLs na nagre-redirect, nagbabalik ng errors, nangangailangan ng cookies, blocked ng robots.txt, o may noindex.

Isa ito sa pinakamadaling checks na i-automate. I-crawl ang site mo at i-flag ang canonical targets na hindi nagbabalik ng malinis na 200 response.

Paghahalo ng canonical at noindex na parang pareho ang ibig sabihin

Magkaibang problema ang nilulutas ng rel="canonical" at noindex.

Gamitin ang canonical kapag may duplicates at gusto mong pagsamahin ang signals sa preferred URL. Gamitin ang noindex kapag ayaw mong ma-index ang isang page.

Ang paggamit ng dalawa nang magkasama ay nagpapadala ng awkward na mensahe: “Huwag i-index ang page na ito, pero gamitin din ito bilang duplicate signal para sa ibang page.” Madalas itong nagagawan ng paraan ng search engines, pero hindi ito malinis na instruction. Kung duplicate ang page, i-canonicalize ito. Kung hindi ito dapat lumabas sa search at wala itong kapaki-pakinabang na duplicate relationship, isaalang-alang ang noindex.

Isang praktikal na canonical audit

Hindi mo kailangan ng malaking SEO platform para makakita ng maraming canonical problems. Magsimula sa crawl, ilang URL samples, at spreadsheet.

Para sa bawat importanteng template, suriin:

1. May eksaktong isang canonical tag ba ang page? Lumilikha ng ambiguity ang maraming canonical tags.
2. Absolute ba ang canonical? Gamitin ang buong URL, kasama ang protocol at hostname.
3. Nagbabalik ba ng 200 OK ang canonical target? Iwasan ang redirected, blocked, o erroring targets.
4. Indexable ba ang canonical target? Walang noindex, walang robots block, walang authentication requirement.
5. Tunay bang equivalent ang content? Hindi palaging equivalent ang similar.
6. Nagtutugma ba ang internal links? Mag-link sa canonical URL format hangga’t maaari.
7. Nagtutugma ba ang sitemap? Sa pangkalahatan, dapat ilista ng sitemaps ang canonical, indexable URLs.
8. Nagtutugma ba ang hreflang tags? Kailangan ng international pages ng consistent canonical at hreflang relationships.
9. Tumutugma ba ang rendered HTML sa raw HTML? Maaaring baguhin o mag-inject ng tags ang JavaScript.
10. Anong canonical ang pinili ng search engine? Maaaring ipakita ng inspection tools kapag iba ang declared canonical mo sa selected canonical.

Dito rin maaaring makatulong ang Lighthouse, pero sa loob lang ng limitasyon nito. Maaari nitong i-flag ang ilang crawlability at document issues, pero hindi nito nauunawaan ang commercial intent o canonical strategy mo. Ituring ito bilang isang input, hindi hatol. Kung kailangan mo ng mas kalmadong paraan para ihiwalay ang kapaki-pakinabang na findings mula sa ingay, tingnan kung paano basahin ang isang Lighthouse report nang hindi nagpapanic.

Karaniwang magandang default ang self-referencing canonicals

Dapat karaniwang ideklara ng bawat importanteng indexable page ang sarili nito bilang canonical. Hindi ito dahil hindi ito kayang alamin ng search engines nang walang tag. Ito ay dahil binabawasan ng self-referencing canonicals ang ambiguity kapag lumilikha ng alternate paths papunta sa parehong content ang parameters, tracking links, copied URLs, at CMS quirks.

Para sa malinis na product page, karaniwang tama ito:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Para sa tracking URL, karaniwang dapat tumuro pabalik ang canonical sa clean version:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Para sa tunay na ibang product variant, depende ang sagot. Kung ang red shirt, blue shirt, at black shirt ay may parehong description at kulay lang ang nagbabago, maaaring sapat na ang isang canonical product page. Kung may hiwalay na demand, reviews, images, stock, at internal links ang bawat variant, maaaring makatuwiran ang hiwalay na indexable pages.

Walang universal canonical rule para sa variants. Mayroon lamang tanong: mapagpapalit ba ang mga page na ito para sa isang searcher?

Dapat tumugma ang canonical tags sa aktuwal na URL policy ng site mo

Karamihan sa canonical bugs ay sintomas ng mas malalim na URL policy problem. Hindi pa napagpapasyahan ng site kung mahalaga ba ang trailing slashes, kung dapat mag-resolve ang uppercase URLs, kung pinapayagan ba ang parameters, kung nagre-redirect ba ang HTTP sa HTTPS, o kung canonical ba ang www.

Pumili ng isang malinis na version ng bawat URL at pagkaisahin ang buong system:

• I-redirect ang non-preferred URL versions sa preferred versions.
• Mag-link internally sa preferred versions.
• Ilagay ang preferred versions sa XML sitemaps.
• Gumamit ng self-referencing canonicals sa preferred pages.
• I-canonicalize lamang ang tunay na duplicates sa preferred URL.

Kapag ang lahat ng signal na ito ay nakaturo sa iisang direksiyon, nagiging boring ang canonical tags. Iyon ang layunin.

Ang pinakabuod

Makapangyarihan ang canonical tags dahil naiimpluwensiyahan nila ang indexing at signal consolidation. Delikado sila sa parehong dahilan.

Hindi palaging aalisin ng maling canonical ang isang page mula sa search. Maaaring balewalain ito ng search engines. Pero hindi estratehiya ang umasa sa search engines na iligtas ang masasamang signal. Ang mas ligtas na paraan ay ilaan ang canonicalization para sa tunay na duplicates, panatilihing malinis at indexable ang targets, at tiyaking iisa ang kuwento ng iyong internal links, redirects, sitemaps, at canonicals.

Hindi lugar ang canonicals para itago ang magulong architecture. Dito mo kinukumpirmang nalinis na ito.