لینک‌سازی داخلی و Topic Cluster؛ Audit، Mapping و سنجش

یک سایت ۲۵۰ مقاله دارد و ظاهراً «لینک‌سازی داخلی» را رعایت کرده است: هر مقاله ده‌ها لینک Tag دارد، همه به خانه وصل‌اند و یک Pillar نیز فهرست نود صفحه را نشان می‌دهد. بااین‌حال سه URL برای یک Intent رقابت می‌کنند، صفحه درآمدی مهم فقط از Sitemap پیدا می‌شود، چند لینک از Redirect عبور می‌کنند و کاربر پس از خواندن هر مقاله نمی‌داند گام بعدی چیست. تعداد Link زیاد است؛ معماری تصمیم وجود ندارد.

Topic Cluster یک فرمول رسمی رتبه‌بندی Google نیست. یک Operating model برای سازمان‌دهی محتوا، انتخاب URL مالک هر Job، ساخت مسیر قابل‌خزش و هدایت کاربر است. ارزش آن وقتی ظاهر می‌شود که Inventory، Intent-to-URL map، لینک Crawlable، Canonical سالم، Anchor توصیفی، اندازه‌گیری و Governance کنار هم باشند. این راهنما همان سیستم را از Audit تا انتشار و بازبینی می‌سازد.

خلاصه اجرایی: سیستم لینک داخلی سالم چه می‌کند؟

1. برای هر Audience job و Search intent، URL مالک یا مرز روشن تعیین می‌کند.
2. هر صفحه مهم از مسیر HTML قابل‌خزش و قابل‌فهم برای کاربر دسترس‌پذیر است.
3. Pillar/Hub به‌جای فهرست Keyword، نقشه تصمیم و مسیر ورود به جزئیات است.
4. لینک Contextual فقط وقتی اضافه می‌شود که مقصد «گام بعد، توضیح لازم یا تصمیم مرتبط» باشد.
5. Anchor متن مقصد را توصیف می‌کند و همیشه به URL نهایی ۲۰۰/Canonical می‌رود.
6. Orphan، Dead end، Redirect chain، Duplicate intent و Link imbalance با Graph audit پیدا می‌شوند.
7. اثر با Crawl/Index، Query-page fit، Navigation و Outcome سنجیده می‌شود؛ نه صرفاً تعداد Link یا Bounce rate.

مرز این مقاله با «آتوریتی موضوعی»

راهنمای آتوریتی موضوعی و Topic Cluster مالک انتخاب Scope، Taxonomy، E-E-A-T، برنامه محتوایی و ساخت مرجعیت است. این صفحه مالک اجرای Internal linking و Content graph است: Inventory، Node/Edge audit، Pillar/Cluster mapping، Anchor، Canonical/Redirect، Cannibalization workflow، QA و Measurement. یک راهنما می‌گوید «کدام قلمرو را با چه شواهدی پوشش دهیم» و دیگری می‌گوید «URLها چگونه به هم متصل، ممیزی و نگهداری شوند».

Google چه می‌گوید و چه نمی‌گوید؟

راهنمای رسمی Link best practices گوگل می‌گوید Linkهای قابل‌خزش معمولاً باید عنصر <a> دارای href باشند و Anchor به انسان و Google برای فهم مقصد کمک کند. راهنمای ساختار سایت فروشگاهی Google نیز توضیح می‌دهد که رابطه Linkها، تعداد گام تا صفحه و لینک‌های ورودی داخلی می‌توانند درک اهمیت نسبی صفحات را شکل دهند.

اما Google نگفته است که:

• Topic Cluster یک Ranking factor مستقل و نام‌گذاری‌شده است؛
• هر Pillar باید دقیقاً ۵، ۱۰ یا ۲۰ Cluster داشته باشد؛
• هر مقاله باید عدد ثابتی لینک داخلی بگیرد؛
• Contextual link همیشه وزن مشخصی بیشتر از Navigation دارد؛
• Exact-match anchor سهم اجباری یا «پروفایل طبیعی» عددی می‌خواهد؛
• ساخت Cluster، رتبه یا Indexing را تضمین می‌کند.

بنابراین مدل را برای User journey، Crawlability، Information architecture و نگهداری بسازید؛ از ادعای الگوریتمی فراتر از مستندات پرهیز کنید.

واژه‌نامه عملی: Node، Edge، Hub و Cluster

• Node: URL نهایی قابل‌نمایش در Graph؛ معمولاً Canonical page.
• Edge: لینک از Source URL به Target URL با نوع و Anchor مشخص.
• Hub/Pillar: صفحه‌ای که Scope را توضیح و مسیرهای مهم را سازمان‌دهی می‌کند.
• Cluster/Supporting page: صفحه مالک یک زیرJob/Intent با عمق کافی.
• Orphan: صفحه‌ای که از Graph Crawlable سایت لینک ورودی ندارد.
• Near-orphan: صفحه‌ای با یک ورودی ضعیف، تصادفی یا فقط Boilerplate.
• Dead end: صفحه‌ای بدون مسیر مفید به گام بعد، هرچند Menu/Footer داشته باشد.
• Cannibalization: تعارض واقعی چند URL برای یک نیاز/Query group؛ نه صرفاً نمایش چند صفحه از یک دامنه.

از Audience job شروع کنید، نه از Keyword فهرستی

یک Cluster خوب پاسخ‌های زنجیره‌ای یک مخاطب را مدل می‌کند. برای نمونه مدیر فروشگاه ایرانی درباره درگاه پرداخت ممکن است این Jobها را داشته باشد: انتخاب Provider، Eligibility/قرارداد، Integration، Callback/Verify، خطای پرداخت، Reconciliation، Refund و Security. این‌ها الزاماً یک صفحه یا هشت صفحه نیستند؛ Scope و Intent هر URL از نیاز، Evidence و عمق پاسخ می‌آید.

تحقیق Query و Demand را با راهنمای تحقیق کلمات کلیدی و Intent mapping انجام دهید. Keyword فقط نام تقاضاست؛ URL باید Job، Outcome، Content type و Differentiation را نیز داشته باشد.

Inventory؛ بدون فهرست URL هیچ Cluster واقعی ندارید

Inventory را از CMS export، Sitemap، Crawler، Analytics، Search Console، Server log و Backlink data ترکیب کنید. هیچ منبعی به‌تنهایی کامل نیست. URLهای Parameter، PDF، Media، Pagination و Archived content را نیز با Scope روشن ثبت کنید.

Canonical-first Graph؛ Node تکراری نسازید

پیش از شمارش Link، Redirect و Canonical را Resolve کنید. یک Target ممکن است با HTTP/HTTPS، Slash، Parameter، نسخه چاپ و مسیر قدیمی دیده شود. برای Graph تصمیم، آن‌ها را به Canonical candidate نگاشت کنید اما Evidence خام را نگه دارید تا Link به نسخه نامطلوب پنهان نشود.

راهنمای Canonical گوگل Redirect را سیگنال قوی، rel="canonical" را سیگنال قوی و Sitemap را سیگنال ضعیف‌تر می‌داند؛ Canonical در نهایت Hint است و Google ممکن است URL دیگری انتخاب کند. لینک‌های داخلی باید مستقیماً به URL ترجیحی شما بروند، نه به Duplicate یا Redirect.

Graph audit؛ چه داده‌ای از هر Link بگیریم؟

برای هر Edge این فیلدها را ذخیره کنید: Source canonical، Target خام، Target نهایی، HTTP status، Link type، Anchor text، Surrounding heading/section، Follow state، DOM presence، Template flag و Date. Link type را حداقل به Navigation، Breadcrumb، Body contextual، Related module، CTA و Footer تقسیم کنید.

{
  "source": "/email-automation/",
  "target_raw": "/old-deliverability/",
  "target_final": "/email-deliverability/",
  "status_chain": [301, 200],
  "type": "body-contextual",
  "anchor": "راهنمای تحویل‌پذیری ایمیل",
  "section": "پیش‌نیازهای ارسال",
  "template": false
}

Graph به شما می‌گوید Link وجود دارد؛ Review انسانی می‌گوید آیا برای خواننده در آن نقطه مفید است.

هفت Failure که باید در Audit پیدا شوند

1. Orphan/near-orphan مهم؛
2. Link به 3xx، 4xx، 5xx، noindex یا Canonical دیگر؛
3. Redirect chain و Loop؛
4. Page مهم با Depth یا ورودی نامتناسب با نقش؛
5. Dead end یا Related links نامرتبط؛
6. Anchor مبهم/متناقض یا چند مقصد برای یک وعده؛
7. Template explosion که هزاران Edge کم‌ارزش می‌سازد.

اول سلامت Target را درست کنید؛ افزودن Link بیشتر به صفحه ۴۰۴/Redirect/Noindex کیفیت Graph را بالا نمی‌برد.

Orphan و Near-orphan را چگونه پیدا کنیم؟

خروجی CMS/Sitemap را با URLهای Crawl‌شده از نقطه شروع سایت مقایسه کنید. URL موجود در Inventory که از Graph HTML قابل‌خزش یافت نمی‌شود Candidate orphan است. سپس بررسی کنید آیا intentionally unlinked/noindex است، اشتباه Navigation دارد یا باید ادغام/حذف شود.

Search box جای Link نیست؛ Googlebot معمولاً Query فرم جست‌وجوی داخلی را برای کشف همه صفحات Submit نمی‌کند. Sitemap Discovery را کمک می‌کند، اما Architecture قابل‌فهم برای کاربر نمی‌سازد. برای Pageهای مهم، مسیر Navigation یا Contextual واقعی لازم است.

Crawl depth را قانون سه‌کلیک نکنید

Depth کوتاه برای صفحات حیاتی مفید است، اما «همه‌چیز حداکثر سه کلیک» قانون جهانی نیست و می‌تواند Menu را متورم کند. Depth را با Role، Demand، Business value و Site size مقایسه کنید. یک Policy نمونه: Service/Category کلیدی از Home یا Navigation سطح بالا، Supporting guide از Hub و صفحات آرشیوی فقط در Archive/Pagination سالم.

Depth را از چند Entry point بسنجید: Home، Navigation، Hub و Sitemap graph. کوتاه‌کردن مصنوعی با Footer صدلینکی تجربه را خراب می‌کند.

In-degree و Out-degree؛ عدد خام کافی نیست

In-degree تعداد Sourceهای یکتا و Out-degree تعداد Targetهای یکتاست. اما Linkهای Menu روی هزار صفحه نباید با یک توصیه Contextual یکسان تفسیر شوند. Metric را بر اساس Template/Body، Cluster، Page type و Unique source normalize کنید.

صفحه با In-degree بالا لزوماً مهم یا باکیفیت نیست؛ شاید Footer link باشد. صفحه با In-degree کم لزوماً مشکل ندارد؛ Policy/legal utility ممکن است عمداً نقش محدود داشته باشد. Metric فقط Trigger بررسی است.

Page authority داخلی را به «Power page» ساده نکنید

Backlink، Traffic یا Internal link بالا می‌تواند Candidate خوبی برای اتصال Contextual باشد، به‌شرطی که مخاطب و موضوع واقعاً مرتبط باشند. لینک از هر صفحه پربازدید به هر صفحه درآمدی، UX و معنا را ضعیف می‌کند. PageRank داخلی دقیق و قابل‌مشاهده نیست؛ ابزارهای امتیازدهی Third-party نیز مدل‌اند، نه خروجی Google.

برای Prioritization، External recognition، Organic entry، In-degree، Relevance، Freshness و Business role را کنار هم بگذارید. Link را فقط وقتی اضافه کنید که جمله و مسیر خواننده آن را توجیه کند.

Pillar خوب، Index مفید است؛ نه مقاله غول‌آسا

Hub باید Scope، انتخاب‌ها و مسیرهای اصلی را به‌قدر کافی توضیح دهد. اگر فقط صد عنوان لینک‌شده دارد، ارزش Editorial کم است؛ اگر همه جزئیات صفحات Supporting را تکرار کند، Duplicate intent و نگهداری پرهزینه می‌سازد. Pillar مناسب این ویژگی‌ها را دارد:

• Audience و Job مرکزی روشن؛
• Scope پایدار و قابل‌نام‌گذاری؛
• خلاصه تصمیم و Navigation به زیرJobها؛
• Evidence/Experience مختص خود؛
• Owner و Lifecycle؛
• ارزش مستقل حتی قبل از کلیک روی Supporting page.

برای معماری Taxonomy/Navigation و Card sorting به راهنمای ساختار سایت و معماری اطلاعات مراجعه کنید.

Cluster size از Coverage می‌آید، نه سهمیه محتوا

Cluster سه صفحه‌ای می‌تواند کامل باشد و Cluster سی‌صفحه‌ای می‌تواند پر از تکرار باشد. برای هر Candidate این Gateها را بپرسید:

• Job/Intent مستقل دارد؟
• Result type یا Content format متفاوت می‌خواهد؟
• Evidence/Example/Workflow کافی برای صفحه مستقل دارد؟
• مالک و Refresh budget دارد؟
• از URL موجود به‌طور روشن Differentiated است؟

اگر پاسخ‌ها ضعیف‌اند، Section بهتر از URL تازه است. تولید انبوه برای «پوشش کامل» می‌تواند صفحات کم‌ارزش بسازد؛ راهنمای People-first content گوگل نیز بر Audience، Purpose، Original value و رضایت از پاسخ تأکید می‌کند، نه Word count یا تولید زیاد.

Intent-to-URL map؛ قرارداد مالکیت صفحه

برای مقیاس بزرگ، AI می‌تواند Query grouping و Candidate similarity پیشنهاد دهد، ولی تصمیم Intent/URL نیازمند SERP snapshot، Content review و Business context است. راهنمای تحقیق کلمات کلیدی با AI مرز Clustering و ارزیابی انسانی را پوشش می‌دهد.

Cannibalization را با «دو URL در یک Query» تشخیص ندهید

ممکن است Google برای یک Query دو URL مکمل نشان دهد یا URLها در Queryهای متفاوت سهم داشته باشند. تعارض زمانی محتمل است که چند صفحه وعده، Intent، Content type و Query group مشابه دارند و Impression/Click بین آن‌ها بی‌ثبات یا Landing نامناسب است.

Workflow تشخیص:

1. Query→URL data را در بازه کافی استخراج کنید.
2. URLها را با Impression/Click/Position/Conversion و زمان مقایسه کنید.
3. Title/H1/Promise/Section overlap و SERP intent را Review کنید.
4. Technical duplicate/Canonical mismatch را جدا کنید.
5. تصمیم Keep+Differentiate، Merge+Redirect، Rewrite یا Deindex محدود بگیرید.

Canonical برای Duplicate/Very similar است؛ برای حل دو Intent متمایز از Canonical به‌عنوان چسب استفاده نکنید. Redirect زمانی مناسب است که URL قدیمی واقعاً Retire و مقصد جایگزین باشد.

چهار جهت Link در یک Cluster

«هر Supporting حتماً باید به Hub لینک دهد» می‌تواند Policy مفیدی باشد، اما اگر Link برای کاربر بی‌معناست آن را مکانیکی نکنید. Architecture باید الگو بسازد، نه متن مصنوعی.

Anchor text؛ توصیفی، مختصر و هم‌راستا با مقصد

Anchor خوب قبل از کلیک انتظاری درست می‌سازد. «اینجا کلیک کنید» یا URL خام Context کمی دارد؛ Anchor بسیار طولانی و انباشته از Keyword نیز خوانایی را خراب می‌کند. برای فارسی، عبارت طبیعی و هم‌خوان با جمله بنویسید: «راهنمای ممیزی Canonical و Redirect» بهتر از «سئو، سئو داخلی، آموزش سئو تکنیکال» است.

Exact match داخلی ذاتاً ممنوع نیست و نیازی به ساخت درصد مصنوعی Branded/Generic ندارد. تنوع باید از Contextهای واقعی بیاید. یک Anchor ثابت با مقصدهای متفاوت مشکل معماری می‌سازد؛ وعده‌های متفاوت برای یک مقصد نیز می‌تواند Positioning را مبهم کند.

Context و محل Link؛ در نقطه تصمیم لینک دهید

بهترین محل جایی است که خواننده سؤال بعدی دارد، اصطلاحی نیازمند عمق است یا برای اجرا به ابزار/راهنمای دیگر می‌رود. یک Link در مقدمه فقط چون «بالای صفحه» است لزوماً مفید نیست. Related module نیز اگر بر اساس Content/Intent دقیق ساخته شود ارزش دارد؛ اگر صرفاً آخرین مطالب باشد Noise می‌سازد.

Navigation، Breadcrumb، Body و Footer Jobهای متفاوت دارند. از ادعای وزن ثابت برای محل‌ها پرهیز کنید و User path/Crawlability را بسنجید.

Link باید واقعاً Crawlable باشد

<!-- مناسب -->
<a href="/guides/internal-link-audit/">راهنمای ممیزی لینک داخلی</a>

<!-- برای Navigation قابل اتکا نیست -->
<span onclick="openGuide()">راهنمای ممیزی لینک داخلی</span>

JavaScript event، Click handler بدون href یا URL فقط پس از تعامل ممکن است توسط Crawler قابل استخراج نباشد. لینک نهایی را در Rendered HTML بررسی کنید. برای Pagination و Infinite scroll نیز URLهای واقعی و Link قابل‌خزش بسازید.

به Canonical ۲۰۰ لینک دهید، نه Redirect

پس از تغییر Slug یا Merge، Internal links را Update کنید. Redirect برای Backward compatibility لازم است، اما Graph داخلی باید مستقیم باشد. این کار Chain، Latency و ambiguity را کم می‌کند. Validation حداقل شامل Status مستقیم، Final URL، Canonical self-reference/expected، robots/noindex و Content marker است.

یک Link به URL ۲۰۰ که Canonical آن صفحه دیگری است نیز Target نهایی ایده‌آل نیست؛ مقصد ترجیحی را انتخاب کنید.

Template automation؛ قدرت و Blast radius

Breadcrumb و Related-content engine می‌توانند هزاران Link درست یا اشتباه بسازند. Rule را با Cluster/Content type/Intent/Language/Status محدود کنید. Candidate باید ۲۰۰/Indexable/Canonical، تازه و واقعاً مرتبط باشد. Manual override، exclusion، max count، fallback و QA sample داشته باشید.

AI suggestion را مستقیماً Publish نکنید. Model ممکن است Anchor نامناسب، URL قدیمی، رابطه ظاهری یا Sensitive cross-link بسازد. Human approval و public direct-status check لازم است.

Faceted navigation، Pagination و Archive

Category/Tag/Filter می‌تواند Graph را متورم و Duplicate URL بسازد. هر Taxonomy باید Audience job، Content inventory، Index policy و Owner داشته باشد. Tag خودکار صرفاً برای Link count ارزش ندارد. Filterهای ترکیبی را با Crawl control، Canonical/robots و Internal link policy هماهنگ کنید.

Pagination باید به Pageهای عمیق‌تر مسیر واقعی بدهد؛ Infinite scroll بدون URL/Link جایگزین Discovery کامل نیست. Archiveهای کم‌ارزش را با Pillar اشتباه نگیرید.

اولویت‌بندی اصلاحات؛ Impact × Evidence × Confidence

Priority = (business impact × search/user evidence × confidence)
           / (effort × regression risk)

Candidateهای معمول با اولویت بالا:

• صفحه درآمدی/راهنمای اصلی Orphan یا Near-orphan؛
• Internal linkهای پرتکرار به Redirect/۴۰۴؛
• دو URL واقعاً Cannibalizing با تصمیم Merge روشن؛
• Hub پربازدید که مسیر بعدی ندارد؛
• Content تازه و قوی که از صفحات مرتبط قدیمی لینک نگرفته؛
• Template rule دارای Blast radius بالا.

برای Audit سراسری Crawl/Index/Content/Link از چک‌لیست ممیزی کامل SEO استفاده کنید.

Baseline را قبل از تغییر ثبت کنید

حداقل چهار لایه Metric بسازید:

Bounce rate و Time on page را Signal مستقیم رتبه معرفی نکنید. خروج سریع می‌تواند پاسخ سریع و موفق باشد؛ ماندن طولانی می‌تواند سردرگمی باشد. Outcome و Task context لازم است.

Search Console شاهد است، نه Crawl کامل سایت

مستند رسمی Links report در Search Console صریحاً می‌گوید گزارش فهرست جامع همه Linkها نیست، داده‌ها می‌توانند Sample/Truncated/Deduplicated و URLها بر اساس Canonical گروه‌بندی شوند. برای Audit کامل، Crawler/CMS/Rendered DOM/Server log را کنار GSC بگذارید.

Performance data نیز Queryهای ناشناس/کم‌حجم و بعضی Rowها را کامل نشان نمی‌دهد. نبود داده مساوی نبود Demand یا Link نیست.

اندازه‌گیری تغییر بدون ادعای علیت

قبل/بعد ساده با Seasonality، Update محتوا، تغییر SERP، Backlink، Campaign و الگوریتم مخدوش می‌شود. Change log دقیق با Source/Target/Anchor/Date/Reason نگه دارید. برای مجموعه بزرگ، Cohort صفحه‌های مشابه و گروه Holdout یا Rollout مرحله‌ای بسازید.

Window را با Crawl/Index latency و حجم داده انتخاب کنید. افزایش Position پس از Link یک همبستگی است مگر طراحی آزمایش و Confound control قوی داشته باشید. Decision را با چند لایه Metric بگیرید، نه یک نمودار.

Content lifecycle؛ Cluster یک پروژه یک‌باره نیست

هر انتشار جدید باید Owner URL و Links-in/Links-out پیشنهادی داشته باشد. هر Update باید Broken/Redirected target، Anchor promise و مرز Intent را Review کند. هر Retirement باید Merge/Redirect، Link replacement، Sitemap/Canonical و Measurement annotation داشته باشد.

Review cadence را بر Risk و Decay تنظیم کنید: موضوع قانون/قیمت/نرم‌افزار سریع‌تر؛ مبانی پایدار کندتر. انتشار تاریخ تازه بدون تغییر substantive ارزش Refresh نیست.

Governance و RACI لینک داخلی

هیچ ابزار یا Writer نباید به‌تنهایی URL جدید، Merge و Redirect را بدون Map و Review تصویب کند. این تصمیم‌ها هم Content و هم Technical SEO را تغییر می‌دهند.

نمونه ایران: Cluster درگاه پرداخت فروشگاه

Hub با Job «از انتخاب تا بهره‌برداری امن درگاه» ساخته می‌شود. Supportingها بر Intentهای مستقل مالکیت می‌گیرند: مقایسه/قرارداد Provider، Integration فنی، Callback/Verify/Idempotency، Reconciliation مالی، خطا/Incident، Refund و Security. صفحه «اتصال فنی» به Hub برای Overview، به Reconciliation به‌عنوان گام بعد و به Incident برای Failure path لینک می‌دهد؛ به صفحه مقایسه فقط وقتی کاربر هنوز Provider را انتخاب نکرده است.

دو مقاله قدیمی درباره «حل خطای پرداخت» با Query/Promise یکسان پیدا می‌شوند. تیم Content را Merge، بهترین URL را نگه، دیگری را مستقیم ۳۰۱ و همه Internal linkها را به مقصد نهایی Update می‌کند. Hub فهرست خشک نیست؛ Decision map، مسئولیت‌ها و انتخاب مسیر دارد. Metricها شامل Orphan صفر برای صفحات اصلی، Link-to-final-۲۰۰، Query→owner URL stability، کلیک مسیر و Lead مشاوره است.

Roadmap نودروزه اجرای لینک‌سازی داخلی

روز ۱ تا ۳۰: Inventory، Graph و Intent map

• URLها را از CMS/Sitemap/Crawl/GSC/Analytics/Log جمع کنید.
• Canonical/status/indexability و Edgeهای HTML را استخراج کنید.
• Orphan، Redirect/۴۰۴، Depth و Duplicate-intent candidate را صف‌بندی کنید.
• برای یک Cluster مهم، Audience job و Owner URL map بسازید.

روز ۳۱ تا ۶۰: Pilot، اصلاح و QA

• یک Hub و ۵ تا ۱۰ URL موجود را Pilot کنید؛ عدد، سقف پروژه است نه قانون Cluster.
• لینک‌های 3xx/4xx/Canonical mismatch را مستقیم اصلاح کنید.
• Anchor و Context را دستی Review و Cannibalization واقعی را Merge/Differentiate کنید.
• Public ۲۰۰/Canonical/robots/Rendered link و User path را Test کنید.

روز ۶۱ تا ۹۰: اندازه‌گیری، Automation و Scale

• Change log و Dashboard چندلایه را با Baseline مقایسه کنید.
• Ruleهای موفق را به Brief/Editor/CMS suggestion تبدیل کنید.
• Template automation را محدود، نمونه‌گیری و Kill switch تعریف کنید.
• Cluster بعدی را با Impact/Evidence/Confidence اولویت دهید.

چک‌لیست Definition of Done

• Audience job و Owner URL هر صفحه روشن است.
• Topic Cluster به‌عنوان مدل عملیاتی است، نه Ranking factor تضمینی.
• Inventory از چند منبع ساخته و Canonical-first شده است.
• هر Target مستقیم ۲۰۰، Indexable و Canonical مورد انتظار است.
• هر صفحه مهم حداقل یک مسیر HTML قابل‌خزش و مفید دارد.
• Orphan، Near-orphan، Dead end، 3xx/4xx و Template explosion Review شده‌اند.
• Pillar ارزش مستقل و مسیر تصمیم دارد؛ فقط Link list نیست.
• Cluster page Job مستقل و Exclusion روشن دارد.
• Anchor توصیفی/مختصر و هم‌راستا با وعده مقصد است.
• Cannibalization با Query→URL و Content review اثبات شده است.
• Merge با Redirect و Update لینک‌های داخلی کامل شده است.
• Baseline، Change log، Rollout و Metricهای User/business ثبت شده‌اند.
• Owner، RACI، Review cadence و Stale-link SLA وجود دارد.

پرسش‌های متداول

آیا Topic Cluster یک فاکتور رسمی رتبه‌بندی گوگل است؟

Google آن را به‌عنوان Ranking factor مستقل اعلام نکرده است. Cluster یک الگوی معماری محتواست که می‌تواند رابطه صفحات، Discovery و مسیر کاربر را بهتر کند؛ رتبه به کیفیت، ارتباط، رقابت، سلامت فنی و عوامل متعدد دیگر وابسته است.

آیا Pillar باید به همه Cluster pageها لینک بدهد؟

اگر همه آن صفحات مسیرهای اصلی و مفید Scope هستند، Link مستقیم منطقی است. اما فهرست‌کردن هر URL فقط برای کامل‌کردن مدل لازم نیست. Sub-hub، Category و مسیر مرحله‌ای می‌تواند برای Cluster بزرگ خواناتر باشد.

هر مقاله چند لینک داخلی باید داشته باشد؟

عدد جادویی وجود ندارد. هر Link باید مقصد مرتبط، سالم و مفید برای گام کاربر داشته باشد. صفحه کوتاه شاید دو لینک و راهنمای عمیق بیش از هشت لینک مفید داشته باشد؛ سهمیه ثابت معمولاً Noise می‌سازد.

آیا Exact-match anchor در لینک داخلی بد است؟

نه به‌صورت مطلق. اگر عبارت نام طبیعی مقصد است، استفاده از آن منطقی است. مشکل زمانی است که Anchorها برای Keyword stuffing مصنوعی، بسیار طولانی، مبهم یا متناقض با مقصد شوند. درصدسازی Branded/Generic برای لینک داخلی لازم نیست.

برای یافتن Orphan و Cannibalization چه داده‌ای لازم است؟

Orphan را با مقایسه CMS/Sitemap/Analytics/GSC با Crawl HTML پیدا کنید. Cannibalization به Query→URL performance، Title/H1/Promise overlap، SERP intent و Canonical/status review نیاز دارد. یک ابزار یا یک Query به‌تنهایی حکم نهایی نمی‌دهد.

جمع‌بندی: لینک داخلی، سیستم تصمیم است

یک Topic Cluster مؤثر با فلش‌های زیبا در Spreadsheet ساخته نمی‌شود. باید معلوم باشد هر URL مالک چه Jobی است، Link چرا در آن نقطه وجود دارد، Target نهایی سالم است، تعارض صفحه چگونه حل می‌شود و نتیجه برای کاربر و کسب‌وکار چه بوده است.

از Inventory و یک Cluster پایلوت شروع کنید. Graph را Canonical-first بسازید، Failureهای فنی را قبل از افزودن Link رفع کنید، Anchor را برای انسان بنویسید و تغییر را با Change log و چند لایه Metric بسنجید. در این مدل، لینک‌سازی داخلی از تاکتیک Keyword به زیرساخت قابل‌نگهداری محتوا تبدیل می‌شود.