اسکیما Person برای معرفی ساختاریافته یک فرد به موتورهای جستجو استفاده میشود. با این نوع Schema Markup میتوان اطلاعاتی مثل نام، تصویر، عنوان شغلی، سازمان محل فعالیت، پروفایلهای معتبر و حوزههای کاری یک متخصص، نویسنده یا عضو تیم را به شکل استاندارد مشخص کرد.
اگر صفحه شما بهطور مشخص درباره یک فرد است، مانند صفحه نویسنده، «درباره من» یا پروفایل یکی از اعضای شرکت، مستندات فعلی گوگل الگوی ProfilePage را ارائه میکنند که در آن همان شخص با نوع Person به عنوان mainEntity صفحه معرفی میشود. این ساختار میتواند درک گوگل از هویت فرد و ارتباط او با محتواهای سایت را شفافتر کند، اما به تنهایی تضمینی برای Knowledge Panel یا نمایش ویژه در نتایج نیست.
اسکیما Person چیست؟
Person یکی از Typeهای Schema.org برای توصیف یک فرد است. این ساختار میتواند اطلاعاتی از هویت پایه شخص تا شغل، ارتباط با سازمانها، تصویر، وبسایت و صفحات دیگری که به همان فرد تعلق دارند را در خود جای دهد. Schema.org استفاده از Person را فقط به افراد مشهور محدود نکرده است.
بنابراین Person Schema میتواند برای افراد مختلفی استفاده شود، از جمله:
- نویسندگان سایت
- پزشکان و متخصصان
- مدیران و اعضای کلیدی شرکت
- مشاوران
- پژوهشگران
- مدرسها
- بنیانگذاران
- صاحبان برند شخصی
مهم این است که صفحه واقعا درباره همان فرد باشد و اطلاعاتی که در Structured Data وارد میکنید با محتوای قابل مشاهده صفحه هماهنگی داشته باشد.
کاربرد Person Schema در صفحات سایت
اسکیما Person زمانی بیشترین معنا را دارد که صفحه، یک فرد مشخص را به عنوان موضوع اصلی معرفی کند. گوگل در راهنمای ProfilePage، صفحه نویسنده در سایت خبری، صفحه «About Me» در وبلاگ و صفحه کارمند در سایت شرکت را از نمونههای معتبر صفحه پروفایل میداند.
صفحات مناسب برای این ساختار عبارتاند از:
- صفحه اختصاصی نویسنده
- صفحه درباره من
- صفحه معرفی پزشک یا متخصص
- صفحه عضو تیم
- صفحه مدیر یا بنیانگذار
- صفحه پروفایل فرد در یک پلتفرم
در مقابل، اگر یک صفحه درباره دهها عضو تیم است و هیچ فردی موضوع اصلی صفحه محسوب نمیشود، بهتر است برای افراد مهم صفحه اختصاصی ایجاد شود. گوگل برای ProfilePage تاکید میکند که تمرکز اصلی صفحه باید روی یک شخص یا یک سازمان باشد.
تفاوت Person و ProfilePage
یکی از مهمترین نکات در پیادهسازی جدید این است که Person و ProfilePage یک چیز نیستند.
Person خود فرد را توصیف میکند؛ مثلا علی رضایی یک متخصص سئو است، در فلان شرکت فعالیت میکند و چند پروفایل رسمی دارد.
ProfilePage خود صفحهای را توصیف میکند که موضوع اصلی آن همان فرد است.
در ساختاری که گوگل برای صفحات پروفایل مستند کرده، الگوی کلی به این شکل است:
{
“@context”: “https://schema.org”,
“@type”: “ProfilePage”,
“mainEntity”: {
“@type”: “Person”,
“name”: “نام شخص”
}
}
گوگل برای ProfilePage، وجود mainEntity را الزامی میداند و این مقدار میتواند Person یا Organization باشد. برای Person نیز name یا در شرایط مشخص alternateName برای شناسایی فرد استفاده میشود.
بنابراین برای یک صفحه اختصاصی متخصص یا نویسنده، استفاده از ProfilePage و قرار دادن Person داخل mainEntity ساختار روشنتری نسبت به قرار دادن چند Property پراکنده Person بدون مشخص کردن موضوع اصلی صفحه ایجاد میکند.
مهمترین فیلدهای Person Schema
Schema.org Propertyهای زیادی برای Person دارد، اما قرار نیست همه آنها را صرفا برای بزرگتر شدن JSON-LD وارد کنید. خود گوگل نیز توصیه میکند اطلاعات کمتر اما دقیق و کامل، بهتر از تعداد زیادی Property ناقص یا نادرست است.
jobTitle، worksFor، affiliation، alumniOf و knowsAbout همگی Propertyهای معتبر Person در Schema.org هستند.
استفاده از name و alternateName
در name نام اصلی و عمومی فرد را وارد کنید. اگر شخص نام هنری، نام مستعار یا شناسه شناختهشده دیگری دارد، میتوان آن را در alternateName تعریف کرد.
برای ProfilePage، گوگل name را شیوه اصلی شناسایی شخص میداند و در شرایطی که نام اصلی وجود ندارد، alternateName نیز میتواند برای این هدف استفاده شود.
استفاده از image
در image باید تصویر مرتبط با همان فرد قرار بگیرد. گوگل برای ProfilePage تاکید میکند URL تصویر قابل Crawl و Index باشد و تصویر واقعا موجودیتی را که Markup شده نمایش دهد.
از قرار دادن تصویر پیشفرض سایت، لوگو یا آواتار عمومی به جای عکس فرد خودداری کنید.
استفاده از jobTitle
jobTitle برای عنوان شغلی فعلی شخص است؛ برای مثال:
“jobTitle”: “SEO Specialist”
Schema.org برای jobTitle هم Text و هم DefinedTerm را میپذیرد. در بیشتر پیادهسازیهای معمول، یک عنوان متنی دقیق و قابل فهم کافی است.
تفاوت worksFor و affiliation
این دو Property معمولا با یکدیگر اشتباه گرفته میشوند.
worksFor برای سازمانی است که فرد برای آن کار میکند. Schema.org این Property را مشخصا برای «Organizations that the person works for» تعریف کرده است.
مثال:
“worksFor”: {
“@type”: “Organization”,
“name”: “Example Agency”
}
affiliation مفهوم گستردهتری دارد و برای سازمانی استفاده میشود که فرد با آن وابستگی دارد؛ مثلا دانشگاه، انجمن، باشگاه یا مجموعه حرفهای.
پس اگر میخواهید محل کار فرد را مشخص کنید، worksFor انتخاب دقیقتری است. affiliation را برای هر ارتباط سازمانی به شکل بیهدف استفاده نکنید.
کاربرد sameAs در شناسایی فرد
sameAs یکی از مهمترین Propertyهای Person برای اتصال هویت فرد به صفحات دیگری است که همان شخص را مشخص میکنند.
Schema.org، sameAs را URL صفحهای میداند که بهصورت بدون ابهام همان موجودیت را مشخص میکند و گوگل نیز در ProfilePage امکان درج صفحات یا پروفایلهای خارجی مربوط به فرد را در این Property در نظر گرفته است.
مثال:
“sameAs”: [
“https://www.linkedin.com/in/example”,
“https://example.com/profile/example”
]
هر لینکی را داخل sameAs قرار ندهید. صفحه باید واقعا متعلق به همان فرد یا مرجعی روشن برای شناسایی او باشد.
برای مثال، لینک دادن به یک مقاله تصادفی که فقط یک بار نام شخص را آورده است، کاربرد sameAs نیست.
کاربرد alumniOf و knowsAbout
alumniOf برای معرفی سازمان یا موسسهای است که فرد قبلا عضو یا فارغالتحصیل آن بوده است. برای مثال میتوان دانشگاه محل تحصیل را در این بخش تعریف کرد.
knowsAbout برای موضوعاتی است که شخص درباره آنها دانش دارد. Schema.org صراحتا توضیح میدهد که این Property میتواند حوزه دانش فرد را بیان کند، اما سطح مهارت یا تخصص را تعیین نمیکند.
نمونه:
“knowsAbout”: [
“SEO”,
“Structured Data”,
“Technical SEO”
]
فهرست knowsAbout باید با Bio، سوابق، مقالات و فعالیت واقعی فرد همخوانی داشته باشد. تبدیل آن به فهرست تمام مهارتهای موجود در جهان، کمکی به شفافیت موجودیت نمیکند.
ارتباط Person Schema با نویسنده مقاله
یکی از مهمترین کاربردهای Person Schema در سایتهای محتوایی، اتصال مقاله به نویسنده واقعی آن است.
در Article Structured Data، گوگل author را به صورت Person یا Organization میپذیرد. همچنین برای author.url توصیه میکند URL صفحهای درج شود که نویسنده را به شکل مشخص معرفی میکند. اگر این URL یک صفحه پروفایل داخلی باشد، گوگل توصیه میکند همان صفحه با ProfilePage Structured Data مشخص شود.
یک معماری تمیز میتواند به این شکل باشد:
مقاله
Article → author → Person
صفحه نویسنده
ProfilePage → mainEntity → Person
به این ترتیب، مقاله نام یک نویسنده مبهم را نمایش نمیدهد؛ بلکه به صفحهای متصل میشود که هویت همان نویسنده را توضیح داده است.
این ساختار برای سایتهایی که چند نویسنده یا متخصص دارند اهمیت بیشتری پیدا میکند، چون هر فرد میتواند صفحه اختصاصی و موجودیت مشخص خود را داشته باشد.
ساختار Person برای اعضای یک سازمان
اگر فرد عضو یک شرکت یا مجموعه مشخص است، میتوانید ارتباط او با آن سازمان را از طریق worksFor مشخص کنید.
مثال:
“worksFor”: {
“@type”: “Organization”,
“name”: “Example Company”,
“url”: “https://example.com/”
}
این ارتباط باید واقعی و قابل مشاهده باشد. اگر فرد دیگر در سازمان فعالیت نمیکند، اطلاعات Structured Data نیز باید بروزرسانی شود.
در سایتهایی که هم هویت شرکت و هم افراد کلیدی اهمیت دارند، Organization و Person میتوانند در کنار هم یک ساختار معنایی روشنتر ایجاد کنند؛ یکی سازمان را مشخص میکند و دیگری افراد مرتبط با آن را.
نمونه کامل Person Schema با ProfilePage
برای یک صفحه اختصاصی متخصص، ساختاری مشابه نمونه زیر قابل استفاده است:
{
“@context”: “https://schema.org”,
“@type”: “ProfilePage”,
“mainEntity”: {
“@type”: “Person”,
“name”: “علی رضایی”,
“url”: “https://example.com/team/ali-rezaei/”,
“image”: “https://example.com/images/ali-rezaei.jpg”,
“description”: “متخصص سئو و دادههای ساختاریافته”,
“jobTitle”: “SEO Specialist”,
“worksFor”: {
“@type”: “Organization”,
“name”: “Example Agency”,
“url”: “https://example.com/”
},
“knowsAbout”: [
“SEO”,
“Structured Data”,
“Technical SEO”
],
“sameAs”: [
“https://www.linkedin.com/in/example”
]
}
}
اطلاعات نمونه را باید با اطلاعات واقعی همان فرد جایگزین کنید. همچنین Propertyهایی را که اطلاعات معتبر و قابل نمایش برای آنها ندارید حذف کنید.
گوگل JSON-LD را در بیشتر سناریوهای Structured Data پیشنهاد میکند و این فرمت میتواند در <head> یا <body> صفحه قرار بگیرد.
برای بررسی الزامات فعلی صفحه پروفایل نیز میتوانید به مستندات ProfilePage گوگل مراجعه کنید.
محل قرارگیری Person Schema
Person Schema را روی صفحهای قرار دهید که اطلاعات همان شخص را نمایش میدهد.
برای مثال:
- صفحه اختصاصی متخصص
- صفحه نویسنده
- صفحه درباره من
- صفحه اختصاصی عضو تیم
در راهنمای ProfilePage، گوگل صفحهای را معتبر میداند که تمرکز اصلی آن روی همان Person یا Organization باشد.
بنابراین قرار دادن یک Person Schema ثابت برای مدیرعامل روی تمام صفحات سایت انتخاب مناسبی نیست. هر Structured Data باید با موضوع و محتوای صفحهای که روی آن قرار گرفته هماهنگ باشد.
تست Person Schema بعد از پیادهسازی
بعد از اضافه کردن کد، Syntax و ساختار صفحه را بررسی کنید.
مسیر پیشنهادی:
- JSON-LD را تولید کنید.
- کد را در Rich Results Test بررسی کنید.
- خطاهای Critical را رفع کنید.
- صفحه را منتشر کنید.
- URL را در Search Console با URL Inspection بررسی کنید.
- بعد از تغییرات مهم، وضعیت Structured Data را دوباره کنترل کنید.
گوگل نیز در مستندات ProfilePage همین مسیر کلی ساخت، اعتبارسنجی، انتشار و بررسی URL را پیشنهاد میکند.
توجه داشته باشید که معتبر بودن Structured Data تضمین نمیکند یک نمایش ویژه حتما در Search ظاهر شود. گوگل صراحتا چنین تضمینی برای قابلیتهای مبتنی بر Structured Data ارائه نمیکند.
ارتباط Person Schema با گوگل نالج
Person Schema میتواند اطلاعات هویتی یک فرد را به شکل مشخص و قابل پردازش ارائه کند، اما نباید آن را ابزار مستقیم «ساخت Knowledge Panel» معرفی کرد.
برای مثال، sameAs میتواند صفحات دیگری را که همان شخص را معرفی میکنند مشخص کند و worksFor ارتباط فرد با یک سازمان را نمایش دهد. در کنار این اطلاعات، منابع خارجی، صفحات رسمی، محتوای منتشرشده و سایر سیگنالهای موجودیت نیز در تصویر کلی هویت فرد نقش دارند.
بنابراین Person Schema یکی از اجزای ساخت هویت دیجیتال فرد است، نه کل آن. موضوع ارتباط موجودیتها، منابع و نالج پنل را میتوان در ساختار گستردهتر گوگل نالج بررسی کرد.
گوگل نیز تضمین نمیکند که صرف استفاده از Structured Data باعث نمایش یک قابلیت خاص در نتایج شود.
اطلاعاتی که نباید بیدلیل در Person قرار دهید
Schema.org Propertyهای زیادی مثل آدرس، شماره تلفن، تاریخ تولد و اطلاعات دیگر را برای Person تعریف میکند، اما وجود یک Property به این معنی نیست که حتما باید از آن استفاده کنید.
برای یک متخصص یا نویسنده معمولا اطلاعاتی مثل نام، Bio، تصویر، عنوان شغلی، سازمان، URL و صفحات رسمی کاربرد بیشتری دارند.
اطلاعات شخصی یا غیرضروری را صرفا برای کاملتر شدن Schema منتشر نکنید. Structured Data بخشی از محتوای عمومی صفحه است و باید فقط اطلاعاتی را در آن قرار دهید که انتشارشان واقعا منطقی است.
سخن آخر
پیادهسازی Person Schema زمانی ارزشمند است که اطلاعات یک فرد واقعی را به شکل منسجم و قابل فهم در اختیار موتورهای جستجو قرار دهد. برای صفحه اختصاصی متخصص یا نویسنده، بهتر است علاوه بر Person به ساختار ProfilePage نیز توجه کنید و ارتباط نویسنده با مقالات سایت را مشخص نگه دارید.
ساختار عملی را میتوان در چند مرحله خلاصه کرد:
- صفحه اختصاصی فرد را مشخص کنید.
- Person را به عنوان موجودیت اصلی صفحه تعریف کنید.
- نام، تصویر و اطلاعات شغلی واقعی را اضافه کنید.
- محل کار را با worksFor مشخص کنید.
- صفحات معتبر فرد را در sameAs قرار دهید.
- در سایتهای محتوایی، Article را به صفحه نویسنده متصل کنید.
- JSON-LD را تست کرده و همزمان با تغییر اطلاعات فرد بروزرسانی کنید.
Person Schema جایگزین اعتبار حرفهای، سابقه واقعی و منابع معتبر نیست؛ بلکه ساختاری است که این اطلاعات را برای موتور جستجو قابل فهمتر میکند.
سوالات متداول درباره اسکیما Person
اسکیما Person برای چه افرادی مناسب است؟
Person Schema برای معرفی هر فردی که صفحه مشخصی در سایت دارد قابل استفاده است؛ مانند نویسنده، متخصص، پزشک، مدیر، بنیانگذار یا عضو تیم. این Type در Schema.org محدود به افراد مشهور نیست.
تفاوت Person و ProfilePage چیست؟
Person خود فرد را توصیف میکند، در حالی که ProfilePage نوع صفحهای است که درباره یک شخص یا سازمان مشخص ساخته شده است. در الگوی فعلی گوگل، فرد میتواند به عنوان mainEntity از نوع Person داخل ProfilePage قرار بگیرد.
مهمترین فیلدهای Person Schema کداماند؟
برای معرفی معمول یک متخصص، name، url، image، description، jobTitle، worksFor و sameAs از کاربردیترین Propertyها هستند. Propertyهایی مثل alumniOf و knowsAbout نیز در صورت مرتبط بودن قابل استفادهاند.
sameAs در Person Schema چه کاربردی دارد؟
sameAs برای اشاره به URLهایی استفاده میشود که همان فرد را بدون ابهام مشخص میکنند؛ مانند یک پروفایل معتبر یا صفحه رسمی دیگر.
Person Schema را روی همه صفحات سایت قرار دهیم؟
خیر. بهتر است Person روی صفحهای استفاده شود که واقعا درباره همان فرد است. برای ProfilePage نیز گوگل تاکید دارد تمرکز اصلی صفحه باید روی یک شخص یا سازمان باشد.
آیا Person Schema باعث ساخت Knowledge Panel میشود؟
خیر. Structured Data میتواند اطلاعات فرد و روابط او را شفافتر کند، اما گوگل نمایش قابلیتهای خاص مبتنی بر Structured Data را تضمین نمیکند. بنابراین Person Schema را نباید کلید قطعی ساخت Knowledge Panel دانست.
