Tukuyin muna kung tunay ngang duplicate ang mga URL
Ang canonical URL ang kinatawang address para sa mga duplicate o halos duplicate na pahina. Ang canonical link relation ay angkop kapag ang target ay naglalaman ng duplicate na nilalaman o isang superset ng nilalaman ng tumutukoy na pahina. Hindi ito paraan para itago ang magkakaibang produkto, kapaki-pakinabang na filter, artikulo, o locale.
Tanungin kung mawawala ba sa bisita ang mahahalagang nilalaman, pagpipilian, o kakayahang matapos ang gawain kung ang URL na ito ay ire-representa ng candidate URL. Kung oo, panatilihing hiwalay ito at pagandahin ang nilalaman o lokalization nito. Kung hindi, piliin ang isang matatag na URL at idokumento ang protocol, host, path, trailing-slash, at patakaran sa mga parameter.
Maglagay ng self-referencing canonical sa bawat preferred indexable HTML page, kahit walang halatang duplicate ngayon.
Ituro ang isang kinakailangang duplicate, tulad ng ruta na may analytics parameter, sa preferred URL lamang kung parehong nagbabalik ang dalawang pahina ng parehong pangunahing nilalaman.
Gumamit ng redirect kapag dapat mawala ang lumang URL
Gumamit ng permanent server-side redirect kapag ang isang lumang path, retired host, o HTTP na bersyon ay hindi na dapat destinasyon ng mga bisita o crawler. Tinuturing ng Google ang mga redirect bilang malakas na signal ng canonicalization at inirerekomenda ito kapag dine-deprecate ang isang duplicate.
Gumamit ng rel=canonical kapag kailangang magbalik ng nilalaman ang parehong mga URL pero isa ang dapat kumatawan sa cluster sa paghahanap. Hindi binabago ng tag ang address na nakikita ng bisita o tinatanggal ang ibang ruta. Ang target ay dapat magtagumpay at hindi dapat mag-redirect o mag-canonicalize papunta sa ibang lugar.
Ipadala ang legacy HTTP URL nang diretso sa final HTTPS URL at gamitin ang HTTPS URL na iyon sa lahat ng ibang lugar.
Ang robots.txt, URL removals, at noindex ay hindi nagsasaad ng preferred duplicate. Ang noindex ay sa halip humaharang sa isang pahina mula sa Search.
Mag-publish ng iisang malinaw na anotasyon
Para sa HTML, ilagay ang isang absolute rel=canonical annotation sa head. Suriin ang delivered source, hindi lang ang setting sa CMS: ang isang theme, plugin, edge rule, o JavaScript ay maaaring palitan ang value. Pinapayuhan ng Google na ibigay ito sa HTML source at tiyaking hindi ito binabago ng JavaScript.
Para sa non-HTML na dokumento gaya ng PDF, gumamit ng canonical HTTP Link response header kung naaangkop. Iwasan ang magkakasalungat na HTML at header values. Ang target ay dapat ma-access, hindi 4xx response, at hindi isang redirecting o chained URL.
Mag-publish ng iisang canonical target para sa bawat resource; ang maraming target ay nagpapalinaw sa preference.
I-fetch ang sample pages at headers pagkatapos ng template, CDN, CMS, o routing changes at kumpirmahin ang final target.
Pag-isahin ang mga sumusuportang signal
I-link nang internal sa preferred URL sa navigation, breadcrumbs, body links, at generated feeds. Ilagay lamang ang mga URL na nais mong ipakita sa paghahanap sa sitemap. Mahina lang ang signal mula sa sitemap, pero pinapalakas nito ang pagpili kapag tumutugma sa redirects at anotasyon.
Gumawa ng fully qualified sitemap URLs gamit ang parehong host, protocol, at slash style gaya ng canonical. Alisin ang mga redirected at parameterized duplicates. I-test ang automatically generated sitemaps pagkatapos ng permalink, domain, language, o ecommerce changes.
Palitan ang mga link sa tracked, legacy, o alternate-host URLs ng napiling canonical.
Panatilihing pare-pareho ang HTTPS redirects, canonical targets, sitemap, at links; ang mga problema sa certificate at HTTPS-to-HTTP ay nagpapadala ng magkasalungat na signal.
Ituring ayon sa layunin ang mga parameter, pagination, at wika
Hindi awtomatikong duplicate ang mga parameter. Ang analytics parameters ay maaaring hindi magbago ng nilalaman, habang ang mga filter at sorting ay maaaring magbago ng result set. I-test ang mga representative combinations. Panatilihin ang anumang parameter na kinakailangan para sa cart, login, consent, o configuration; ang isang canonical ay hindi dapat masira ang visitor flow.
Huwag i-canonicalize lahat ng pahina ng paginated sa page one: kadalasan may nilalaman ang mga sumunod na pahina na wala sa page one. Para sa mga language o country URL, pangalanan ang same-language page bilang canonical kapag umiiral at gumamit ng hreflang para sa alternates. Hindi pamalit ang canonicalization sa localization design.
Idokumento kung aling mga filter ang natatanging landing pages at alin ang duplicate reorderings upang manatiling naka-align ang product at engineering changes.
Gamitin ang isang 'view-all' lamang kapag ito ay isang usable content superset; i-test ang load at navigation bago piliin ito.
I-debug ang mga conflict gamit ang indexed at live na ebidensya
Sa Search Console, i-inspect ang apektadong URL at i-compare ang indexed Google-selected canonical sa user-declared value. I-inspect din ang candidate target. Ipinapakita ng indexed report kung ano ang huling na-process ng Google; kapaki-pakinabang ang live test para sa kasalukuyang fetch, rendered page, headers, at resources, pero hindi nito maipredict ang final canonical selection.
Kung magkaiba ang mga value, isaalang-alang kung pinili ng Google ang mas mahusay na kinatawan. Kung hindi, i-trace ang redirects, HTML at HTTP-header annotations, rendered output, links, sitemap entries, hreflang, at pagkakatulad ng nilalaman. Ayusin ang hindi pagkakatugma, i-record ang pagbabago, at magbigay ng panahon para sa re-evaluation.
Suriin ang templates, headers, host routing, at security changes. Ang hindi ipinalinaw na cross-domain canonical o redirect ay nangangailangan ng security investigation.
I-compare ang delivered source at headers sa CMS settings; maaaring mag-emit ng ibang value ang isang plugin o platform rule.
Idagdag ang canonical checks sa SIU release hardening
Bago ang domain, HTTPS, CDN, CMS, template, o catalog releases, samplehin ang homepage, content at product pages, isang parameter route, isang locale, isang legacy URL, at mga published document. I-record ang status, final URL, canonical target, sitemap inclusion, at isang halimbawa ng internal-link.
Panatilihing reversible ang mga fixes: kuhanin ang kasalukuyang mapping, baguhin ang isang rule set, i-verify ang apektadong mga ruta, at panatilihin ang rollback plan. Sinusuportahan nito ang proactive uptime optimization sa pamamagitan ng pagprotekta sa matatag na public paths habang nagbabago; hindi ito nagbibigay ng outage detection o garantiya sa pag-index.
Mag-assign ng canonical rules sa pagitan ng marketing at engineering at i-log ang template, redirect, sitemap, o platform change sa bawat update.
I-attach ang maliit na before-and-after URL at header sample sa release ticket para sa mas mabilis na remediation.