معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۵ — Editorial Cell، SEO، QA، Approval و Onboarding · 250
SEO Page Schema و Intent-driven Content
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «SEO Page Schema و Intent-driven Content». می‌تواند «SEO Page Schema و Intent-driven Content» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خلاصهٔ درس
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «SEO Page Schema و Intent-driven Content».
می‌تواند «SEO Page Schema و Intent-driven Content» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خروجی این درس
می‌تواند «SEO Page Schema و Intent-driven Content» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
1) مسئله: «یک صفحه برای هر کلمه» معماری SEO نیست
فرض کنید سه عبارت تجاری نزدیک دارید و برای هرکدام یک landing page جدا می‌سازید. عنوان‌ها متفاوت‌اند، اما دو صفحه تقریباً همان محتوای قبلی را تکرار می‌کنند؛ یکی Product markup دارد درحالی‌که بعضی propertyها اصلاً برای کاربر قابل‌مشاهده نیست؛ و همه به یک CTA عمومی می‌روند. مشکل اینجا کمبود keyword نیست. مشکل این است که Intent، هویت صفحه، محتوای قابل‌مشاهده، canonical، claimها و conversion path از هم جدا شده‌اند.
2) مرز COM-009: Page-Intent Schema، نه Claim Registry و نه QA کل محتوا
مالک این درس SEO Page-Intent Schema v1 است. COM-008 مالک Claim/Source Registry و COM-010 مالک Content QA Rubric است. این درس Search ranking، rich result، index شدن یا conversion را تضمین نمی‌کند و هیچ ابزار Google را به authority انتشار MAKNOW تبدیل نمی‌کند.
3) مدل ذهنی: Intent → Purpose → Canonical Identity → Visible Contract → Markup/Claims → Links/CTA → Approval → Measurement
قبل از انتخاب slug یا schema type، باید بدانیم مخاطب چه مسئله‌ای دارد و صفحه دقیقاً چه کاری برای او انجام می‌دهد. سپس یک page_id و canonical_url پایدار می‌سازیم و visible_content_contract را مشخص می‌کنیم. markup، claimها، internal link role و CTA باید روی همین قرارداد سوار شوند؛ نه اینکه هرکدام در ابزار جداگانه تصمیم بگیرند.
4) FACT: Structured Data توضیح صفحه است، نه وعدهٔ نتیجه
Google structured data را قالب استانداردی برای ارائهٔ اطلاعات صریح دربارهٔ محتوای صفحه معرفی می‌کند. پیاده‌سازی درست می‌تواند صفحه را برای featureهای پشتیبانی‌شده eligible کند؛ اما eligibility به معنی نمایش قطعی rich result، افزایش رتبه یا نتیجهٔ تجاری نیست. در این درس markup_validation_state=PASS فقط یک evidence فنی است، نه state نهایی صفحه.
5) FACT: چیزی را که کاربر نمی‌بیند، صرفاً در markup اختراع نکنید
راهنمای Google می‌گوید structured data باید همان صفحه را توصیف کند و اطلاعاتی که در صفحه برای کاربر قابل‌مشاهده نیست نباید صرفاً در markup اضافه شود. پس visible_content_contract و required_properties باید قابل‌مقایسه باشند. اگر property مهم markup در محتوای visible وجود ندارد، state امن REVISE_MARKUP_VISIBILITY است؛ نه READY.
6) FACT: Canonical یک سازوکار deduplication است، نه تصمیم business taxonomy
Google بین URLهای duplicate یا بسیار مشابه یک URL نماینده انتخاب می‌کند. سیگنال‌های سایت، از جمله rel=canonical، به انتخاب کمک می‌کنند اما انتخاب نهایی همیشه دقیقاً مطابق preference سایت نیست. بنابراین ما canonical را برای هویت و signal consistency ثبت می‌کنیم، ولی از آن نتیجه نمی‌گیریم که دو intent واقعاً باید یک صفحه یا دو صفحه باشند؛ آن بخش تصمیم محصول/محتواست.
7) قرارداد ۲۱ فیلدی: هر صفحه یک پروندهٔ تصمیم قابل‌ممیزی دارد
یک Page-Intent Schema قابل‌دفاع فقط URL و keyword ندارد. باید page_id، audience، problem_intent، query cluster، purpose، canonical، page type، visible contract، structured-data type/properties/validation، claim refs، internal-link role، CTA/destination، indexability، owner/approval، measurement و evidence را کنار هم نگه دارد.
| page_id | problem_intent | canonical_url | visible_content_contract | structured_data_type | primary_cta | approval_state | evidence_ref |
|---|---|---|---|---|---|---|---|
| PAGE-CONSULT-01 | compare options and request consultation | https://example.invalid/consultation | service scope, eligibility, process, evidence-backed outcomes | Service/Organization descriptive metadata (non-rich-result guarantee) | Request consultation | APPROVED | EVID-PAGE-01 |
| PAGE-CONSULT-SYN | compare options and request consultation | https://example.invalid/consultation | near-identical body and same CTA | same as canonical | Request consultation | REVIEW | EVID-DUP-02 |
| PAGE-PRODUCT-03 | evaluate product | https://example.invalid/product-x | name and description visible; price/availability absent | Product | Request quote | REVISE | EVID-MARKUP-03 |
8) Intent و Query Cluster یکی نیستند
Query cluster مجموعه‌ای از عبارت‌هاست؛ intent فرضیه‌ای دربارهٔ task واقعی کاربر است. دو query متفاوت ممکن است یک task واحد داشته باشند و یک صفحهٔ قوی‌تر پاسخ هر دو باشد. برعکس، دو عبارت شبیه ممکن است task متفاوتی داشته باشند و به صفحهٔ جدا نیاز داشته باشند. تصمیم با problem_intent + content_purpose + visible_content_contract گرفته می‌شود، نه با تعداد keyword.
9) Near-duplicate را با صفحهٔ keyword-only حل نکنید
اگر صفحهٔ پیشنهادی فقط synonym دیگری از مقصد موجود است، body تقریباً همان است و CTA هم تفاوتی ندارد، ساخت URL جدید معمولاً evidence کافی ندارد. در مدل ما state CONSOLIDATE_DUPLICATE_INTENT یعنی query cluster و link strategy را به مقصد canonical موجود وصل کنید یا تفاوت واقعی purpose/audience را ثابت کنید؛ صرف canonical tag روی یک duplicate، جای معماری روشن را نمی‌گیرد.
10) Claimها باید با Intent جدید دوباره سنجیده شوند
اگر problem_intent از «آشنایی» به «خرید/درخواست مشاوره» تغییر کند ولی claim set و evidence همان نسخهٔ قبلی بماند، ممکن است صفحه وعده‌هایی را حمل کند که برای تصمیم تجاری جدید کافی یا مناسب نیستند. چنین driftی HOLD_INTENT_CLAIM_DRIFT است تا claim refs با intent و visible content جدید بازبینی شوند.
11) CTA و Conversion Destination ادامهٔ همان وعده‌اند
primary_cta باید next step طبیعی همان page purpose باشد و conversion_destination باید همان اقدام را واقعاً ممکن کند. اگر صفحه وعدهٔ «درخواست دمو» می‌دهد ولی CTA به newsletter عمومی می‌رود، keyword و schema هرقدر خوب باشند، تصمیم REVISE_CTA_INTENT است.
12) Rich Results Test یک test است، نه oracle
قبولی در validator یا Rich Results Test می‌تواند نشان دهد markup از نظر فنی برای feature بررسی‌شده مشکل بحرانی ندارد؛ اما Google صریحاً تضمین نمی‌کند feature نمایش داده شود. اگر تیم از PASS ابزار نتیجه بگیرد «rich result حتماً ظاهر می‌شود» یا «رتبه بهتر می‌شود»، state HOLD_RICH_RESULT_OVERCLAIM است تا ادعا محدود شود.
13) Missing Evidence را با حدس پر نکنید
اگر evidence_ref، canonical purpose، approval یا یکی از ابعاد بحرانی خالی است، مدل اجازه ندارد از keyword volume، model confidence یا رفتار competitor نتیجهٔ مثبت بسازد. HOLD_MISSING_EVIDENCE یعنی هنوز دادهٔ لازم برای تصمیم وجود ندارد؛ این با failure صفحه فرق دارد.
14) Failure Modeها و state درست
- تمام ابعاد بحرانی بسته، visible/markup هم‌خوان، intent و CTA هم‌راستا →
READY - propertyهای markup در visible content پشتیبانی نمی‌شوند →
REVISE_MARKUP_VISIBILITY - CTA یا destination با intent نمی‌خواند →
REVISE_CTA_INTENT - URL جدید near-duplicate و بدون task متمایز است →
CONSOLIDATE_DUPLICATE_INTENT - evidence بحرانی ناقص است →
HOLD_MISSING_EVIDENCE - intent تغییر کرده ولی claim set قدیمی مانده →
HOLD_INTENT_CLAIM_DRIFT - validation به‌عنوان تضمین rich result/ranking استفاده شده →
HOLD_RICH_RESULT_OVERCLAIM - canonical signals با تصمیم صفحه تناقض دارند →
HOLD_CANONICAL_CONFLICT
15) Lab و Transfer: plan را از evidence جدید دوباره بسازید
Lab هشت fixture آفلاین و ۴۸ assertion deterministic دارد. در Transfer، query cluster جدید commercial intent قوی‌تری دارد، اما صفحهٔ پیشنهادی مقصد canonical موجود را duplicate می‌کند و بخشی از markup هم در visible content نیست. پاسخ درست «یک صفحهٔ دیگر چون keyword جدید است» نیست. باید destination موجود را reuse/consolidate کنید یا تفاوت واقعی task را ثابت کنید، markup unsupported را حذف/نمایان کنید و سپس state را دوباره محاسبه کنید.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
COM-009-S1 retrieval
What does COM-009 own, and what outcome remains outside its boundary?
COM-009-S2 application
Build SEO Page-Intent Schema v1 for the baseline three-page fixture.
COM-009-S3 diagnosis
A page adds structured-data facts not visible to users. Which evidence field fails and what state follows?
COM-009-S4 transfer
A stronger-commercial query cluster duplicates an existing canonical destination and proposes invisible markup properties. Recompute the page plan without a keyword-only duplicate.
ملاک‌های ارزیابی (rubric)
- Identity and intent: one stable page identity is bound to a real problem intent and query cluster.
- Canonical purpose: duplicate or near-duplicate destinations are consolidated unless a materially distinct task is evidenced.
- Visible/markup alignment: structured-data properties describe visible page content and supported Search features.
- Claim provenance: commercial/factual claims retain traceable claim registry references after intent changes.
- Conversion alignment: CTA and destination continue the same page promise.
- Typed non-success: missing/conflicting evidence remains REVISE, CONSOLIDATE or HOLD rather than optimistic READY.
- Transfer: changed-context page plan is recomputed instead of copying the baseline URL/markup decision.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
python run_checks.py را اجرا کنید. هر fixture قابل‌مشاهده است و state صفحه فقط از همان evidence محاسبه می‌شود. این آزمایش synthetic و آفلاین است؛ چیزی را در Google منتشر نمی‌کند و نتیجهٔ Search را تضمین نمی‌کند.