ساختار درختی سایت؛ معماری اطلاعات، سئو و UX

کاربر برای دیدن نمودار درختی شما وارد سایت نمی‌شود؛ می‌خواهد «کالای سازگار با مدل دستگاه»، «هزینه خدمت» یا «روش پیگیری سفارش» را پیدا کند. اگر نام دسته‌ها زبان سازمان باشد، یک محتوا زیر چند شاخه سرگردان بماند یا فیلترها هزاران URL تولید کنند، حتی ظاهر مرتب هم Findability نمی‌سازد.

ساختار درختی سایت فقط یکی از Viewهای معماری اطلاعات است. سایت واقعی یک Graph است: Hierarchy برای جهت، Search و Facet برای بازیابی، Navigation برای مسیرهای اصلی، Contextual link برای ارتباط و Sitemap برای Discovery. این راهنما نشان می‌دهد چگونه Inventory و Content model را به Taxonomy، Label، Navigation، URL، Breadcrumb و Link graph تبدیل، با Card sorting/Tree testing آزمایش و با داده UX/SEO نگهداری کنید.

پاسخ کوتاه: ساختار خوب چه اجزایی دارد؟

لایه	سؤال	خروجی
Entity/Content model	چه چیزهایی داریم و چه ویژگی/رابطه‌ای دارند؟	Product، Category، Guide، Service، Policy
Taxonomy	با چه واژگان و قواعدی طبقه‌بندی می‌شوند؟	Controlled vocabulary، Synonym، Parent rule
Hierarchy	مسیر اصلیِ فهم و Browse چیست؟	Home→Section→Category→Item
Navigation	کدام Routeها در چه Contextی دیده می‌شوند؟	Global، Local، Utility، Footer، Contextual
Search/Facet	کاربر چگونه مجموعه بزرگ را محدود می‌کند؟	Query normalization، Filter، Sort، Result state
URL/State	کدام State نشانی پایدار و Indexable دارد؟	URL policy، Canonical، Parameter matrix
Link graph	کدام صفحه از کجا قابل کشف و مهم است؟	Edges، Orphan rule، Hub/Cluster
Governance	چه کسی تغییر می‌دهد و چگونه می‌سنجد؟	Owner، Change log، Test، Sunset/Migration

نمودار درختی بدون قواعد Entity، Label و State به‌سرعت قدیمی می‌شود. همچنین URL کوتاه یا Breadcrumb زیبا بدون Link واقعی و Task success، Architecture موفق را ثابت نمی‌کند.

معماری اطلاعات با ساختار URL یکی نیست

معماری اطلاعات (IA) سازمان‌دهی، نام‌گذاری، بازیابی و مسیر دسترسی به محتوا/قابلیت است. Tree یک نمایش Hierarchical از بخشی از IA و URL فقط Identifier/Address است. Google نیز برای فهم اهمیت نسبی صفحات، بیشتر Linkage میان صفحات را تحلیل می‌کند و لازم نیست Path URL دقیقاً سلسله‌مراتب بصری را بازتاب دهد.

مفهوم	نمونه	اشتباه رایج
Hierarchy	خانه ← لپ‌تاپ ← لپ‌تاپ گیمینگ	فرض اینکه تنها مسیر ممکن است
URL	`/product/legion-5/`	قرار دادن همه Parentهای متغیر در Path
Breadcrumb	خانه ← لپ‌تاپ ← گیمینگ	کپی اجباری URL به‌عنوان مسیر کاربر
Facet	برند، RAM، GPU، قیمت	ساخت URL Indexable برای هر ترکیب
Contextual link	راهنمای انتخاب GPU ← Product	محدود کردن لینک به Parent/Child
XML sitemap	فهرست URLهای Canonical مهم	جایگزین Navigation و لینک داخلی

برای Homepage نیز IA باید Audience→Promise→Route را پشتیبانی کند؛ مقاله طراحی صفحه اصلی مرز Hero/Navigation/Path را جداگانه پوشش می‌دهد.

سایت Tree خالص نیست؛ Graph کنترل‌شده است

یک راهنمای «نحوه انتخاب کفش کوهنوردی» می‌تواند هم برای دسته کفش، هم فعالیت کوهنوردی و هم کاربر مبتدی مفید باشد. مجبور کردن آن به یک مسیر مصرف، Contextهای دیگر را از بین می‌برد. راه‌حل، URL تکراری یا سه نسخه محتوا نیست؛ یک Entity/URL مالک با چند Link زمینه‌دار و یک Parent اصلی برای Browse/Breadcrumb است.

Graph بی‌قاعده نیز خوب نیست. Hubهای بی‌هدف، Tag archive، Related content خودکار و فیلترهای نامحدود می‌توانند Noise بسازند. Edge باید دلیل داشته باشد: Parent/Child، Prerequisite، Alternative، Comparison، Next step یا Evidence.

IA چه Outcomeهایی را می‌تواند بهبود دهد؟

ساختار خوب Mechanism می‌سازد، نه وعده قطعی. Label روشن و Route مناسب می‌تواند زمان یافتن را کم کند؛ لینک قابل Crawl می‌تواند Discovery را آسان‌تر کند؛ Owner URL می‌تواند Intent overlap را کنترل کند. اما کاهش Bounce، افزایش Conversion، Rank یا Sitelink نتیجه تضمینی نیستند.

هدف	Mechanism	Metric	Guardrail
Findability	Label/Grouping/Route	Task success، Directness، Time	Misclick/Backtrack
Discovery	`<a href>` و Sitemap	Orphan، Crawl discovery	URL explosion
Intent ownership	یک Owner برای Job/Cluster	Query/Page overlap	از دست رفتن Coverage مفید
Business path	Route از Need به Outcome	Qualified completion	شکایت/Return/Low-quality lead
Maintainability	Content model و Governance	Time-to-publish، Exception count	Template debt

از Top task و Evidence شروع کنید

ساختار را از چارت سازمانی یا Keyword volume شروع نکنید. ورودی‌های معتبر را مثلث‌سازی کنید:

Interview و مشاهده Task واقعی؛
Search داخلی، Zero-result و اصلاح Query؛
Support/Sales/Chat و دلیل تماس؛
GSC/Analytics/Backend و Landing→Outcome؛
Inventory محتوا و Metadata؛
رقبا در سطح Task/Query، نه کپی Menu؛
قانون، Policy و محدودیت عملیات؛
استراتژی محصول و سناریوی رشد.

برای هر Audience، Job/Trigger/Context/Barrier/Success بنویسید. Persona جمعیت‌شناختی به‌تنهایی نمی‌گوید کاربر «ضمانت سازگاری قطعه با مدل خودرو» را زیر چه Labelی جست‌وجو می‌کند.

Inventory را به Decision sheet تبدیل کنید

فهرست URL فقط نقطه شروع است. Crawl، CMS، Sitemap، Search Console، Analytics، Backlink و Log را Join کنید تا صفحات Orphan یا Stateهای پنهان دیده شوند.

فیلد	نمونه	تصمیم
Entity/Template	Guide/Article	Rule و Owner
Job/Intent	مقایسه قبل از خرید	Owner URL
Canonical/Index state	Indexable canonical	Keep/Merge/Retire
Parent/Edges	Hub X + Product Y	Route و Orphan
Outcome	Qualified lead	Priority
Quality/Freshness	Claim قدیمی	Improve/Archive
Owner/Review	Product Ops/سه‌ماهه	Governance
Migration target	URL Z	Redirect/Update links

Action portfolio شامل Keep، Improve، Merge، Split، Reclassify، Archive، Retire و Create است. همه محتوای موجود حق ماندن در Navigation جدید ندارد و همه Gapها نیز Page تازه نمی‌خواهند.

Content model را پیش از Category tree بسازید

Content model مشخص می‌کند چه Entityهایی وجود دارند، چه Attributeهایی اجباری‌اند و چگونه به هم مرتبط می‌شوند. برای فروشگاه، Product با Category، Brand، Compatibility، Guide، Offer و Policy رابطه دارد؛ برای SaaS، Feature با Use case، Role، Integration، Help article و Release.

Entity	Attribute کلیدی	Relation نمونه
Category	Name، Definition، Scope	contains Product
Product	SKU، Variant، Spec	compatibleWith Model
Guide	Job، Audience، Freshness	helpsChoose Category
Service	Eligibility، Input، Outcome	requires Document
Policy	Scope، Effective date	governs Return

وقتی Relation ساختاریافته است، Related link، Filter و QA قابل اتکا می‌شوند. وقتی همه‌چیز Text آزاد یا Tag خودجوش است، واژگان مترادف و صفحه‌های بدون Owner رشد می‌کنند.

Taxonomy یعنی قرارداد واژگان و طبقه‌بندی

Taxonomy فقط نام Categoryها نیست. برای هر Term این فیلدها را داشته باشید:

Preferred label فارسی و نام انگلیسی/فنی در صورت نیاز؛
Definition و In/Out scope؛
Synonym، Alias، Finglish و شکل ی/ک؛
Parent اصلی و رابطه‌های مجاز؛
Entity/Template قابل استفاده؛
Index/Crawl/Search behavior؛
Owner، Version، تاریخ بازبینی و Deprecation mapping.

Label باید Information scent بدهد. «راهکارها»، «سایر» یا «خدمات ویژه» بدون Context معمولاً ضعیف‌اند. Keyword را به‌زور وارد Label نکنید؛ زبان کاربر، تمایز هم‌سطح و فهم در Navigation مهم‌تر از تکرار عبارت هدف است. اصطلاح LSI keyword نیز مبنای طراحی Taxonomy نیست.

Card sorting برای کشف Mental model است، نه رأی‌گیری نهایی

در Card sort، مشارکت‌کننده Itemها را به گروه‌هایی که برایش معنا دارند می‌چیند. Open sort برای کشف الگو و Label، Closed sort برای بررسی دسته‌های موجود و Hybrid فقط در Scope خاص مفید است. نتیجه خام را مستقیماً به Menu تبدیل نکنید؛ Context صفحه، قانون، عملیات، SEO و Content strategy در کارت‌ها کامل دیده نمی‌شوند.

طرح	کاربرد	خطر
Open	کشف Group و زبان	Label مشارکت‌کننده الزاماً Label نهایی نیست
Closed	Placement در دسته‌های معلوم	Categoryهای بد را تحمیل می‌کند
Hybrid	یک یا دو بخش نسبتاً قطعی	Anchoring و Bias
Moderated	چرایی و ابهام	نمونه کوچک برای درصد قطعی کافی نیست
Unmoderated	Pattern کمی‌تر	کیفیت توجه و Context محدود

Cardها را با واژه‌های تکراری لو ندهید، Pilot اجرا کنید و Item «نامفهوم/هیچ‌جا» را مجاز بگذارید. Participant باید نماینده Audience/Task باشد، نه صرفاً همکار سازمان.

Hierarchy اصلی را با قواعد Placement طراحی کنید

Hierarchy باید Broad enough برای رشد و Distinct enough برای انتخاب باشد. هیچ قاعده جهانی «۲ تا ۷ دسته» وجود ندارد. تعداد و عمق تابع تنوع Entity، Task، Device، Label، Search/Facet و توان Governance است.

قاعده	سؤال کنترل
Mutual clarity	کاربر فرق دو Sibling را می‌فهمد؟
Coverage	Item مهم جای منطقی دارد یا «سایر» می‌شود؟
Stable dimension	Parent با تغییر کمپین/تیم نمی‌شکند؟
Primary parent	برای Breadcrumb/Owner یک مسیر غالب روشن است؟
Cross-list policy	حضور در چند Context بدون URL تکراری چگونه است؟
Growth rule	چه زمانی Category Split/Merge می‌شود؟

قانون سه کلیک را با Cost مسیر جایگزین کنید

سه کلیک یک Threshold علمی جهانی نیست. سه انتخاب مبهم از شش انتخاب روشن بدتر است؛ صفحه پرترافیک ممکن است Link مستقیم بخواهد و Archive کم‌کاربرد عمق بیشتری را تحمل کند. این معیارها مفیدترند:

Task success و First-click correctness؛
Directness و Backtrack؛
Time/Confidence پس از یافتن؛
Click/interaction cost روی Mobile/Keyboard؛
Graph distance از Hub مرتبط، نه فقط Homepage؛
Inlink count/context برای صفحه مهم؛
Orphan و Dead end.

Tree testing ساختار و Label را بدون ظاهر می‌سنجد

پس از ساخت Tree پیشنهادی، به مشارکت‌کننده Task می‌دهید تا مقصد را فقط از میان Category/Labelها پیدا کند. Layout، تصویر و Search حذف می‌شوند تا Information scent ساختار سنجیده شود.

Metric/شاهد	تفسیر	دام
Direct success	با مسیر مستقیم به جواب رسید	Task با Label جواب را لو ندهد
Indirect success	پس از Backtrack رسید	Success خام اصطکاک را پنهان می‌کند
Failure destination	Label/Parent رقیب کجاست؟	ممکن است بیش از یک جواب معتبر باشد
First choice	Information scent سطح اول	اثر ترتیب گزینه‌ها
Time/Confidence	تردید و هزینه شناختی	Speed تنها کیفیت نیست
Think-aloud	چرایی انتخاب/ابهام	نمونه کیفی درصد جامعه نیست

برای مقایسه دو Tree از طراحی بین‌گروهی استفاده کنید تا یادگیری نسخه اول نسخه دوم را Bias نکند. Tree test جای Usability test کامل نیست؛ Search، Visual hierarchy، Responsive menu و Content page را بعداً در Prototype/Production بسنجید. فرایند Research و نمونه‌گیری در راهنمای تست کاربردپذیری آمده است.

Navigation را به پنج لایه تقسیم کنید

نوع	وظیفه	نمونه
Global	Routeهای اصلی کل سایت	محصولات، خدمات، منابع، پشتیبانی
Utility	کارهای پرتکرار/حساب	جست‌وجو، ورود، سبد، پیگیری
Local	حرکت در یک Section	زیردسته‌ها یا موضوعات Help
Contextual	قدم بعد/رابطه معنایی	مقایسه، راهنما، سازگاری، پیش‌نیاز
Footer	Policy/Company/مسیرهای کم‌تکرار	شرایط، حریم خصوصی، تماس

هر Link را در Global menu نگذارید. منوی بزرگ بدون Group/Focus/Keyboard مناسب، Findability را بدتر می‌کند. Navigation باید در صفحات هم‌نوع سازگار باشد، State فعلی را نشان دهد و در Mobile فقط به Icon مبهم فروکاسته نشود.

Search داخلی شریک Navigation است

Search شکست Navigation نیست؛ برای Catalog بزرگ، SKU، مدل، نام خاص و کاربر Expert مسیر طبیعی است. اما Search تنها نیز کافی نیست، چون کاربر ممکن است واژه دقیق را نداند.

Normalization فارسی برای ی/ک، فاصله/نیم‌فاصله و عدد؛
Synonym و Alias کنترل‌شده؛
Typo tolerance با Guardrail؛
Entity-aware ranking برای Product/Guide/Policy؛
Filter و Sort پس از Query؛
Zero-result با پیشنهاد قابل توضیح؛
Log بدون PII و Feedback loop به Taxonomy.

Search queryهای داخلی را Demand خام ندانید؛ Query می‌تواند ناشی از Navigation بد، موجودی ناموجود یا Campaign باشد. Zero-result، Reformulation، Click و Outcome را کنار هم تحلیل کنید.

Faceted navigation به State matrix نیاز دارد

فیلتر برای کاربر مفید است، ولی ترکیب Brand×Color×Size×Price×Sort می‌تواند فضای تقریباً بی‌نهایت URL بسازد. هر Facet را با تقاضا، مجموعه پایدار، محتوای متمایز و هزینه Crawl تصمیم‌گیری کنید.

State	User value	URL	Crawl/Index policy
Landing منتخب	تقاضا و مجموعه پایدار	پایدار/Canonical	Link و Index candidate
Filter کاربردی	Browse موقت	Parameter استاندارد	معمولاً خارج از Index؛ Policy دقیق
Sort/View	نمایش متفاوت، محتوای یکسان	Parameter	Index value ندارد
Empty/نامعتبر	بدون نتیجه	همان URL	۴۰۴ مطابق طراحی فنی/راهنمای جاری
Session/Tracking	ارزش محتوایی ندارد	نباید Internal link شود	از Inventory حذف

Canonical، nofollow یا robots هرکدام Semantics و محدودیت دارند؛ نسخه یکسان برای همه Facetها ندهید. Transition نیز مهم است: اگر URL ابتدا noindex می‌خواهد، باید برای Crawl قابل دسترس بماند تا Directive دیده شود. معماری کامل Catalog/Facet/Variant در راهنمای سئو فروشگاه اینترنتی و Delivery policy در راهنمای robots.txt آمده است.

URL پایدار است؛ چارت سازمانی متغیر

URL خوب Unique، قابل Crawl، پایدار و تا حد امکان توصیفی است. لازم نیست تمام Parentها را حمل کند. اگر محصول از «لوازم سفر» به «کمپینگ» منتقل شود، /product/sku-name/ می‌تواند ثابت بماند؛ Path عمیق مبتنی بر Category هزینه Redirect و خطا را بالا می‌برد.

اصل	نمونه درست	خطر
یک Content، یک URL ترجیحی	`/guide/hiking-shoes/`	نسخه در چند Folder
Case ثابت	Lowercase policy	`/Shoes/` و `/shoes/`
Parameter معنایی	`?page=2`	`?session=...`
Pagination یکتا	هر Page URL مستقل	همه Pageها URL یکسان
Fragment	درون‌صفحه	تغییر محتوای Indexable با `#`
Slug توصیفی	کوتاه و پایدار	Keyword stuffing یا تاریخ زودمنقضی

اگر URL فعلی سالم است، فقط برای زیباتر شدن تغییر ندهید. Benefit باید از هزینه Redirect، Re-crawl، Link update و Risk بیشتر باشد.

Link graph را مثل محصول طراحی کنید

هر صفحه‌ای که باید کشف شود، باید از یک صفحه قابل کشف با Link واقعی <a href> قابل دسترس باشد. Search form، JavaScript event و XML sitemap به‌تنهایی جای این Edge را نمی‌گیرند.

Edge type	Source→Target	هدف
Structural	Category→Subcategory/Product	Browse/Discovery
Upward	Detail→Category/Hub	Orientation
Contextual	Guide→Related guide/Product	Next question
Comparative	Product A↔Alternative B	Decision
Evidence	Claim→Policy/Source	Trust
Operational	Error/Empty→Recovery	خروج از Dead end

Anchor باید مختصر و توصیفی باشد اما exact-match اجباری یا تکراری نیست. Related links خودکار را با Relation/Quality/Availability فیلتر کنید. Inlink count به‌تنهایی Priority نیست؛ Context، Placement، Template و User value نیز مهم‌اند.

Crawl، Index و Rank سه مرحله متفاوت‌اند

Hierarchy و Link می‌توانند Discovery را بهتر کنند؛ Google همچنان ممکن است Page را Crawl نکند، Canonical دیگری انتخاب کند یا Index نکند. Sitemap نیز Suggestion است و تضمین Crawl/Index فوری نیست. اگر صفحه مهم پیدا یا Index نمی‌شود، مرحله شکست را با راهنمای عیب‌یابی ایندکس تشخیص دهید.

Crawl budget برای همه سایت‌ها پروژه جدا نیست

راهنمای پیشرفته Google عمدتاً برای سایت‌های حدود یک‌میلیون URL با تغییر متوسط، ۱۰هزار URL پرتغییر روزانه، یا سهم بزرگ Discovered – currently not indexed است. برای اغلب سایت‌های کوچک، Sitemap سالم و گزارش Page Indexing کافی‌تر از وسواس روی «بودجه» است. بااین‌حال URL explosion، Duplicate و Server error در هر اندازه‌ای Debt فنی‌اند.

XML Sitemap فهرست Canonical مهم است، نه IA کاربر

Sitemap را از Source of truth تولید کنید و فقط URLهای ترجیحی، قابل Index و با Status درست را بگذارید. lastmod باید تغییر معنادار و واقعی را بازتاب دهد. ارسال مکرر همان Sitemap، Crawl فوری نمی‌سازد.

HTML sitemap فقط وقتی برای Task کاربر مفید است اضافه شود؛ Dump هزاران Link جای Navigation نیست. اگر کاربران برای یافتن محتوای اصلی به HTML sitemap وابسته‌اند، IA/Navigation مشکل دارد.

Breadcrumb مسیر کاربر است، نه رونویسی Path

Breadcrumb به Orientation و بازگشت به سطح بالاتر کمک می‌کند. یک صفحه ممکن است چند Context داشته باشد؛ Parent اصلی و سیاست چند Breadcrumb را آگاهانه تعیین کنید. Google نیز توصیه می‌کند Breadcrumb مسیر معمول کاربر را نشان دهد و لزوماً URL را آینه نکند.

Linkهای قابل کلیک تا Parentهای واقعی؛
نام کوتاه و هم‌راستا با Label؛
Current item با State معنایی؛
RTL و ترتیب خواندن صحیح؛
BreadcrumbList هم‌راستا با محتوای قابل مشاهده؛
تست Rich Results و URL Inspection، بدون تضمین نمایش.

Schema فقط Representation است و IA خراب را ترمیم نمی‌کند. برای Governance داده ساختاریافته، راهنمای Schema/JSON‑LD را ببینید.

Sitelink را نمی‌توان سفارش داد

Sitelinkهای Google خودکار و وابسته به Query هستند. Title/Heading روشن، ساختار منطقی، Link به صفحات مهم و Anchor مرتبط می‌توانند کیفیت ورودی را بهتر کنند، اما نمایش یا CTR مشخص را تضمین نمی‌کنند. هدف IA را «Task success» بگذارید؛ Sitelink را Outcome ثانویه مشاهده کنید.

Intent ownership کنیبالیزیشن را دقیق‌تر می‌کند

دو صفحه با واژه مشترک الزاماً مشکل ندارند و دو صفحه با Keyword متفاوت می‌توانند یک Job را تصاحب کنند. برای هر Cluster این‌ها را ثبت کنید:

فیلد	نمونه
Audience/Job	خریدار تازه‌کار؛ انتخاب لپ‌تاپ
Intent/Stage	Comparison/Evaluation
Owner URL	راهنمای انتخاب
Supporting URLs	GPU، RAM، Brand guide
SERP overlap	Query/Page در GSC
Decision	Keep/Merge/Reposition/Redirect

Merge فقط وقتی انجام شود که Job/Scope و Evidence هم‌پوشانی واقعی دارد. Category‌بندی منظم به‌تنهایی Cannibalization را «جلوگیری» نمی‌کند؛ Content brief، Internal link و Owner governance لازم‌اند.

Accessibility بخشی از Navigation است

Landmarkهای header/nav/main/footer و ترتیب DOM منطقی؛
Skip link برای عبور از Menu تکراری؛
Keyboard operation و Focus visible/Not obscured؛
نام/نقش/حالت برای Menu، Accordion و Disclosure؛
Heading hierarchy بدون استفاده صرفاً بصری؛
Current page و Expanded state قابل اعلام؛
Target size، Zoom/Reflow و Mobile orientation؛
Navigation سازگار و بیش از یک راه برای یافتن محتوای مهم در Scope مناسب.

Overlay menu زیبا که Focus را حبس یا Escape را نادیده می‌گیرد، IA قابل استفاده نیست. Automated audit را با Keyboard و فناوری کمکی ترکیب کنید.

بومی‌سازی معماری اطلاعات برای فارسی و ایران

مسئله	ریسک	کنترل
ی/ک و نیم‌فاصله	Search zero-result و Tag تکراری	Normalization و Preferred label
فارسی/Finglish/نام لاتین	Alias گم می‌شود	Synonym registry و Search log
تومان/ریال	ابهام Label و فیلتر قیمت	واحد صریح در همه Stateها
استان/شهر/منطقه	Hierarchy جغرافیایی بی‌ثبات	Entity location و قواعد Landing
RTL/Bidi	Breadcrumb/SKU/عدد وارونه	`dir`، isolation و تست
تقویم/تاریخ	Filter و Archive مبهم	نمایش و Storage contract
Mobile/شبکه	Mega menu سنگین یا غیرقابل لمس	Progressive disclosure و Task test
محدودیت Service خارجی	Route به Feature غیرقابل استفاده	Eligibility registry و جایگزین مجاز

Transliteration خودکار Label نهایی نیست. برای واژه تخصصی، فارسی روشن را Label اصلی و English term را در Context/Glossary نگه دارید. ساخت چند Category برای شکل‌های املایی مختلف به‌جای Synonym، IA را می‌شکند.

مثال فرضی: فروشگاه قطعات خودرو

فروشگاه ۱۲هزار SKU دارد. Tree اولیه «قطعات موتور/بدنه/برقی» است، اما کاربران اغلب با خودرو/مدل/سال و سپس قطعه شروع می‌کنند. راه‌حل لزوماً معکوس کردن کل Tree نیست:

Product یک URL پایدار و Compatibility relation ساختاریافته دارد؛
Hierarchy اصلی برای Browse نوع قطعه باقی می‌ماند؛
Selector خودرو یک Context/Facet کنترل‌شده می‌سازد؛
Landingهای تقاضادار مانند «لنت پژو ۲۰۶» با Rule و محتوای متمایز انتخاب می‌شوند؛
ترکیب‌های بی‌نتیجه ۴۰۴ صحیح و به جای URL بی‌نهایت کنترل می‌شوند؛
Guide انتخاب قطعه به Category/Product سازگار Link می‌دهد؛
Search، SKU و نام بازاری Aliasها را پوشش می‌دهد.

Tree test سناریو «برای ۲۰۶ تیپ ۵ مدل ۱۳۹۹ لنت جلو پیدا کنید» را می‌سنجد؛ Usability test سپس Selector، Filter، Result و Compatibility evidence را در UI واقعی بررسی می‌کند.

مثال فرضی: مرکز راهنمای SaaS

ساختار قدیمی بر نام تیم‌هاست: Engineering، Success و Finance. کاربر اما «اولین راه‌اندازی»، «اتصال»، «خطای پرداخت» و «مدیریت دسترسی» می‌خواهد. Content model شامل Feature، Task، Role، Error code و Plan می‌شود. Navigation بر Journey/Task، Search بر Error/Feature و Contextual link بر Prerequisite/Next step ساخته می‌شود. تیم داخلی Owner می‌ماند اما نامش Parent عمومی نیست.

Governance؛ چه زمانی Category تازه بسازیم؟

درخواست Stakeholder یا وجود چند محتوا کافی نیست. Gate پیشنهادی:

معیار	شاهد
User need متمایز	Research/Search/Support
Coverage کافی	Entity/Content قابل نگهداری
Sibling distinction	Definition و Tree test
Business/Policy fit	Owner و Outcome
SEO state	Intent/Index/Canonical policy
Operational capacity	Publish/Review/Archive SLA
Migration impact	URL/Link/Redirect/Analytics plan

Taxonomy change request باید Term، دلیل، Alternatives، Scope، Owner، Test و Rollback داشته باشد. «موقت برای کمپین» بهتر است Navigation/landing زمان‌دار باشد، نه Parent دائمی Catalog.

Migration ساختار را مثل تغییر Schema اجرا کنید

Inventory کامل URL/Entity/Link/Traffic/Outcome؛
Old→New mapping یک‌به‌یک یا Consolidation مستدل؛
Target readiness شامل Content/Metadata/Canonical/Schema؛
Redirect مستقیم و بدون Pattern خطرناک؛
به‌روزرسانی Internal link، Menu، Breadcrumb و Sitemap؛
تست موبایل/دسکتاپ، Role، Language و State؛
Launch با Snapshot، Owner و Rollback؛
Monitoring ۴۰۴/Redirect/Index/Task/Outcome با Lag مناسب.

Redirect همه صفحات حذف‌شده به Homepage یا Parent نامرتبط Soft failure می‌سازد. اگر جایگزین واقعی نیست، ۴۰۴/۴۱۰ می‌تواند درست‌تر باشد. دستورالعمل فنی و تست ماشینی در راهنمای مهاجرت URL آمده است.

Metric tree ساختار سایت

لایه	Metric	سؤال تشخیصی
Research	Top-task coverage	Taskهای مهم در Tree/Route هستند؟
Tree	Direct success/First choice	Label/Parent کجا گمراه می‌کند؟
UI	Task success/Time/Backtrack	Interaction یا IA مشکل دارد؟
Search	Zero result/Reformulation	Synonym/Content/Ranking Gap چیست؟
Graph	Orphan/Depth/Inlink/Dead end	Discovery و Route کافی است؟
Crawl	URL distribution/Response/Facet	Noise و Error کجاست؟
Index	Reason/Canonical selection	کدام State یا Template Fail است؟
Outcome	Qualified completion/Kept	Findability به نتیجه رسید؟
Guardrail	Support/Return/Complaint	مسیر ظاهراً کوتاه کیفیت را کم کرد؟

Average click depth را تنها KPI نکنید. صفحه Utility کم‌مصرف با عمق چهار ممکن است سالم باشد؛ صفحه Revenue با First-click failure جدی‌تر است. Segment بر Task، Audience، Device، Template و Source لازم است.

آزمون فنی و QA خودکار

هر URL Indexable از Link قابل Crawl دست‌کم یک مسیر دارد؛
Canonical/Status/robots/Sitemap با State matrix هم‌راستاست؛
Redirect chain/loop و Internal redirect وجود ندارد؛
Breadcrumb visible و JSON-LD parity دارد؛
Menu/Breadcrumb/Facet با Keyboard و Screen reader قابل استفاده‌اند؛
Pagination و Lazy/infinite loading Link fallback دارند؛
Empty/Invalid combination Status صحیح دارد؛
Taxonomy term بدون Owner/Definition وارد Production نمی‌شود؛
Content مهم در Mobile و Desktop Link parity دارد؛
Analytics event برای Search/Filter/Navigation QA شده است.

این کنترل‌ها را در ممیزی سراسری با Backlog و Acceptance ترکیب کنید؛ چک‌لیست ممیزی کامل سئو Scope فنی بزرگ‌تر را پوشش می‌دهد.

خطاهای رایج در طراحی ساختار سایت

خطا	پیامد	اصلاح
چارت سازمانی = IA	Label و Scope نامفهوم برای کاربر	Top task و Research
Tree = URL	تغییر Category همه URLها را می‌شکند	Identifier پایدار و Mapping جدا
قانون سه کلیک	Flattening و Menu متراکم	Task cost/Directness
هر Keyword = Page/Category	Thin/overlap/Taxonomy debt	Intent ownership و Content model
Tag آزاد	Synonym و Archive کم‌ارزش	Controlled vocabulary
Sitemap جای Link	Browse/Importance ضعیف	Graph قابل Crawl
Facet Indexable پیش‌فرض	URL explosion و Duplicate	State matrix
Breadcrumb آینه URL	مسیر کاربر بی‌معنا	Typical user path
Category بدون Owner	Empty/Stale/Exception	Governance و Sunset
Redesign بدون Baseline	اثر قابل سنجش نیست	Tree/UX/Crawl snapshot

برنامه ۳۰/۶۰/۹۰روزه

روز ۱ تا ۳۰: Inventory و مدل

Top task، Audience/Job و Business outcome را تثبیت کنید.
URL/CMS/Sitemap/GSC/Analytics/Log inventory را Join کنید.
Entity، Attribute، Relation و Templateها را تعریف کنید.
Taxonomy registry و Intent owner اولیه بسازید.
Baseline Tree/Search/Graph/Crawl/Outcome بگیرید.

روز ۳۱ تا ۶۰: Research و Prototype

Card sort هدفمند و مصاحبه تکمیلی اجرا کنید.
Hierarchy، Navigation، Search و Facet state را طراحی کنید.
دو Tree را با Taskهای بدون Priming آزمایش کنید.
URL/Breadcrumb/Internal-link و Index policy را Contract کنید.
Migration mapping و Risk register بسازید.

روز ۶۱ تا ۹۰: Pilot و Rollout

یک Section/Template را با لینک و State واقعی Pilot کنید.
Usability/Accessibility/Crawl/Schema/Analytics QA را Pass کنید.
Redirect و Internal-link update را ماشینی تست کنید.
Launch مرحله‌ای با Alert/Owner/Rollback انجام دهید.
Outcome با Lag مناسب و Taxonomy exception را بازبینی کنید.

چک‌لیست کیفیت معماری اطلاعات

IA از Top task و Evidence شروع شده، نه چارت سازمانی.
Entity/Attribute/Relation و Owner روشن‌اند.
Taxonomy Definition/Synonym/Scope/Version دارد.
Hierarchy، URL، Breadcrumb و Link graph جدا اما هم‌راستا هستند.
Primary parent و Cross-list policy تعریف شده‌اند.
Search فارسی و Facet state matrix آزموده شده‌اند.
هیچ عدد جادویی برای Category/Click بدون Evidence اعمال نشده است.
صفحات مهم Link واقعی و Route کاربری دارند.
Sitemap فقط Canonicalهای مطلوب را فهرست می‌کند.
Crawl/Index/Rank و Sitelink وعده قطعی نشده‌اند.
Tree testing با Task درست و Usability test مکمل اجرا شده است.
Keyboard/Focus/RTL/Bidi/Mobile پوشش دارند.
Migration، Redirect، Monitoring و Rollback آماده‌اند.
Metric tree تا Outcome/Guardrail ادامه دارد.

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

ساختار درختی سایت دقیقاً چیست؟

نمای سلسله‌مراتبی Routeهای اصلی از Home به Section/Category/Detail است. اما IA کامل‌تر است و Content model، Taxonomy، Search، Facet، Navigation، URL، Breadcrumb، Link graph و Governance را نیز شامل می‌شود؛ سایت واقعی Graph کنترل‌شده است.

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

عدد جهانی ندارد و قانون سه کلیک Threshold علمی ثابت نیست. Task success، First click، Directness، Backtrack، هزینه تعامل، اهمیت صفحه و Graph distance از Hub مرتبط را بسنجید. عمق کمتر با Label مبهم بهتر نیست.

آیا URL باید دقیقاً ساختار دسته‌بندی را نشان دهد؟

خیر. URL باید پایدار، یکتا، قابل Crawl و ترجیحاً توصیفی باشد. Google ساختار را عمدتاً از Linkage می‌فهمد. قرار دادن Parentهای متغیر در Path می‌تواند هزینه Migration را بالا ببرد؛ Breadcrumb نیز Typical user path است، نه الزاماً URL.

آیا XML Sitemap صفحات بدون لینک داخلی را حل می‌کند؟

Sitemap به Discovery کمک می‌کند اما Suggestion است و جای Navigation/Link واقعی یا تضمین Index نیست. صفحه مهم باید از Page قابل کشف با <a href> دسترس‌پذیر و در Journey منطقی باشد؛ Orphan بودن را در Sourceها مقایسه کنید.

آیا تغییر ساختار پس از راه‌اندازی خطرناک است؟

قابل انجام است، اما بدون Inventory، Old→New mapping، Target readiness، Redirect مستقیم، Update لینک/منو/Sitemap، QA و Monitoring ریسک دارد. URL سالم را فقط برای زیبایی عوض نکنید و برای Target نامرتبط Redirect عمومی نسازید.

جمع‌بندی: درخت برای جهت، Graph برای واقعیت

ساختار سایت خوب از تعداد Category یا شکل URL شروع نمی‌شود. Entity و Task را می‌شناسد، Taxonomy را قرارداد می‌کند، Hierarchy اصلی را با Routeهای Search/Facet/Contextual تکمیل و هر State را برای User/Crawl/Index روشن می‌کند.

یک Section را انتخاب کنید؛ Inventory و Top task را بسازید؛ Tree را با Card sort و Tree testing اصلاح؛ Prototype را با کاربر و Keyboard آزمون؛ و Rollout را با Link/Redirect/Monitoring اجرا کنید. موفقیت زمانی است که کاربر مقصد را با اطمینان پیدا کند، سیستم بتواند ساختار را نگه دارد و موتور جست‌وجو Linkهای مطلوب را ببیند—نه اینکه نمودار درختی صرفاً مرتب به نظر برسد.

خدمات مایندیو

تست ریل

تیمی

تسکی

برچسب‌ها