سئو گالری تصاویر و ویدئو؛ کشف، سرعت و سنجش

صفحه یک محصول ۱۸ عکس و دو ویدئو دارد، اما Google فقط تصویر اول را می‌بیند. Thumbnailها با CSS ساخته شده‌اند، بقیه اسلایدها پس از Click می‌آیند، URL فایل‌ها امضای چنددقیقه‌ای دارد و اسکیمای Product هنوز عکس Variant قبلی را اعلام می‌کند. گالری برای کاربر «پر» است، ولی برای Crawl، Accessibility و داده محصول ناقص.

سئو گالری تصاویر و ویدئو با تکرار کلمه کلیدی در Alt حل نمی‌شود. باید یک زنجیره سالم بسازید: Search intent → صفحه میزبان → Asset/Variant → HTML قابل کشف → Delivery سریع → Metadata و Schema هم‌خوان → تجربه قابل استفاده → Measurement. این راهنما دقیقاً همین سیستم را برای گالری محصول، نمونه‌کار، مقاله، املاک و Media library طراحی و ممیزی می‌کند.

مرز این راهنما: گالری یک Component است، نه فقط مجموعه فایل

مقاله تصویر و ویدئو در طراحی سایت مالک چرخه عمومی انتخاب، تولید، Delivery، Accessibility و Measurement رسانه است. سئو محتوای غیرمتنی نیز Search ownership را برای Image، Podcast، Infographic و Interactive asset پوشش می‌دهد. این صفحه روی مسئله خاص گالری متمرکز است: چند Asset و Rendition، ترتیب اسلاید، Variant، Lightbox، Pagination، صفحه میزبان، Duplicate media URL و سازگاری آن‌ها با Search.

Search owner را قبل از کدنویسی تعیین کنید

Lightbox معمولاً یک حالت رابط است، نه صفحه مقصد مستقل. اگر برای هر عکس URL جدا می‌سازید، باید ارزش، عنوان، Context، Canonical و Navigation واقعی داشته باشد. در WordPress، Attachment pageهای کم‌محتوا را کورکورانه Index نکنید؛ تصمیم Redirect/Noindex/Keep باید با Inventory و نقش Search هر صفحه ثبت شود.

مدل داده گالری را پیش از Audit بسازید

یک فایل در پوشه Uploads، Asset کامل نیست. Source، Rendition، محل استفاده، حقوق و وضعیت انتشار باید قابل ردیابی باشند. حداقل Schema عملیاتی:

gallery_item {
  asset_id
  owner_page_url
  product_or_entity_id
  variant_id
  role: primary | detail | scale | lifestyle | diagram | video
  source_master
  thumbnail_url
  responsive_renditions[]
  full_asset_url
  alt_or_accessible_name
  caption_and_context
  rights_owner | license | expiry
  schema_reference
  status: draft | live | retired
}

برای فروشگاه پوشاک ایرانی، «مانتوی مدل آوا ـ سبز ـ نمای پشت» باید به Variant سبز وصل باشد؛ نه اینکه با انتخاب رنگ مشکی همچنان عکس سبز، Alt سبز و Product.image قدیمی بماند. تولید Shot list و دقت رنگ/SKU در راهنمای عکاسی محصول عمیق‌تر شده است.

کشف تصویر: HTML استاندارد، URL پایدار و دسترسی ربات

مستندات جاری Google Images می‌گوید تصویرهای داخل src عنصر img قابل کشف‌اند و تصویر CSS برای Google Images Index نمی‌شود. پس Thumbnail مهم را صرفاً background-image نسازید. برای Art direction یا Format fallback، picture مجاز است، اما یک img src واقعی نگه دارید.

<picture>
  <source type="image/avif" srcset="coat-green-640.avif 640w, coat-green-1280.avif 1280w">
  <source type="image/webp" srcset="coat-green-640.webp 640w, coat-green-1280.webp 1280w">
  <img
    src="coat-green-1280.jpg"
    srcset="coat-green-640.jpg 640w, coat-green-1280.jpg 1280w"
    sizes="(max-width: 768px) 100vw, 50vw"
    width="1280" height="1600"
    alt="مانتوی مدل آوا سبز، نمای پشت و برش کمر">
</picture>

قرارداد URL و Response

• URL عمومی Asset باید پایدار، Absolute و بدون Token کوتاه‌عمر باشد؛
• Response مستقیم ۲۰۰، MIME مطابق فایل و بایت معتبر برگرداند؛
• robots.txt یا Header ناخواسته مانع Googlebot-Image/Video نشود؛
• CDN Host، Certificate، Redirect و Hotlink policy با Crawler آزمایش شود؛
• برای یک تصویر تکراری تا حد ممکن URL ثابت استفاده شود تا Crawl و Cache بیهوده نشود؛
• حذف/جایگزینی Asset، Policy مشخص ۳۰۱/۴۰۴/۴۱۰ و Usage graph داشته باشد.

نام فایل سرنخ سبک است، نه دلیل مهاجرت انبوه URLهای سالم. تغییر IMG-1.jpg به نام توصیفی فقط وقتی ارزش دارد که هزینه Redirect، Cache، Feed، Embed و History کنترل شود. Context صفحه، Caption و Alt معمولاً مهم‌تر از Rename پرریسک‌اند.

JavaScript، Lazy loading و Infinite gallery را قابل Crawl کنید

Google Search با صفحه تعامل انسانی انجام نمی‌دهد؛ Click روی «نمایش بیشتر» یا Scroll اجباری نباید تنها راه تولید Asset مهم باشد. راهنمای رسمی Lazy-loading گوگل می‌خواهد محتوای مربوط، هنگام قرارگرفتن در Viewport و بدون Action کاربر Load شود و در Rendered HTML قابل مشاهده باشد.

الگوی امن برای گالری بلند

1. Assetهای حیاتی و اسلاید اول را در HTML قابل استفاده قرار دهید؛
2. برای موارد پایین صفحه از Native lazy loading یا IntersectionObserver استفاده کنید؛
3. اگر مجموعه بزرگ است، Chunkهای پایدار با URL یکتا بسازید؛
4. صفحات را با <a href> به‌صورت متوالی لینک کنید؛ Button تنها کافی نیست؛
5. هر صفحه Paginated را Self-canonical کنید؛ همه را به صفحه اول Canonical نکنید؛
6. در Infinite scroll، URL بخش اصلی را با History API به‌روزرسانی و Refresh/Share را تست کنید؛
7. HTML خام، Rendered HTML و تجربه No-JS/Slow-JS را مقایسه کنید.

<nav aria-label="صفحه‌بندی گالری پروژه‌ها">
  <a href="/gallery/?page=1">۱</a>
  <a href="/gallery/?page=2" aria-current="page">۲</a>
  <a href="/gallery/?page=3" rel="next">بعدی</a>
</nav>

rel=next/prev دیگر سیگنال Pagination گوگل نیست؛ ارزش نمونه بالا در Link واقعی و URL پایدار است. Fragment مانند #page=3 را جای URL صفحه‌بندی استفاده نکنید.

Thumbnail، Full image و Rendition را با هم اشتباه نگیرید

Thumbnail برای Navigation گالری است؛ تصویر Responsive برای Slot واقعی؛ Full image برای Zoom یا Download مجاز. ارسال فایل ۴۰۰۰پیکسلی برای Thumbnail ۸۰پیکسلی اتلاف است، اما اگر Full asset فقط پس از Click با URL موقت ساخته شود، ممکن است Search و Share آن را نبینند.

تصمیم Format را از روی درصدهای عمومی نگیرید. برای Corpus عکس محصول، Screenshot، Transparency و متن، کیفیت/بایت/Encode/Decode را بسنجید؛ فرایند کامل در راهنمای AVIF در برابر WebP آمده است.

Alt و Context را بر اساس نقش هر اسلاید بنویسید

Alt هم معادل متنی برای کاربری است که تصویر را نمی‌بیند و هم Context به Search می‌دهد. قرار نیست همه تصاویر نام محصول و فهرست Keyword یکسان داشته باشند.

Caption می‌تواند زاویه، منبع، مقیاس، محدودیت یا نتیجه را برای همه کاربران توضیح دهد. متن اطراف باید واقعاً درباره همان Asset باشد؛ قراردادن عکس نامرتبط کنار پاراگراف Keyword-rich، Context معتبر نمی‌سازد. برای نمودار یا اینفوگرافیک، اعداد، منبع، تاریخ و Method را در HTML قابل خواندن ارائه کنید.

Variant گالری، محتوای مرئی و Schema باید یک حقیقت بگویند

در فروشگاه، انتخاب رنگ یا سایز ممکن است Price، Availability، SKU و Image را عوض کند. این State باید در UI، URL/Canonical policy، Feed و Structured data هماهنگ باشد. اگر Variant URL مستقل و Indexable است، تصویر همان Variant را به‌صورت مرئی و در Markup بدهید. اگر همه Variantها یک URL دارند، Default/selected state و Offerها نباید تناقض بسازند.

• Product.image یا ProductGroup/Variant reference از Source of Truth Catalog بیاید؛
• og:image و primaryImageOfPage نماینده صفحه باشند؛
• Schema به تصویری اشاره نکند که ۴۰۴، Private یا منقضی است؛
• Markup با عکس، عنوان، SKU، رنگ و وضعیت مرئی تطبیق داده شود؛
• تغییر Variant رویداد قابل مشاهده برای Analytics داشته باشد؛
• Cache/CDN پاسخ Variant اشتباه را بین کاربران مخلوط نکند.

Vocabulary معتبر به‌تنهایی Eligibility یا نمایش Rich result را تضمین نمی‌کند. برای Entity graph، Product truth، Variant و CI به راهنمای Schema فروشگاه و خدمات رجوع کنید.

ویدئوی داخل گالری: Asset فرعی یا Search owner؟

ویدئوی چرخش ۳۶۰ درجه در اسلاید پنجم صفحه محصول معمولاً شاهد تصمیم خرید است، نه هدف اصلی صفحه. گوگل برای قابلیت‌های Video توصیه می‌کند—اگر برای کسب‌وکار منطقی است—هر ویدئو Watch page اختصاصی داشته باشد که هدف اصلی آن تماشای ویدئو است. پس افزودن VideoObject به هر Embed کوچک، تضمین Video result نیست.

قرارداد URL و Metadata ویدئو

watch_page_url: صفحه‌ای که کاربر واقعاً ویدئو را می‌بیند
embed_url: URL پلیر مشخص
content_url: URL پایدار فایل/Stream قابل Fetch، اگر قابل ارائه است
thumbnail_url: تصویر معتبر، پایدار و نماینده
visible_fields: name | description | uploadDate | duration
accessibility: captions | transcript | player controls
availability: expiry | region | authentication boundary

Facade یا Poster برای عقب‌انداختن Player می‌تواند Performance را بهتر کند، اما URL ویدئو، Thumbnail و Markup نباید فقط پس از Click انسانی پدیدار شوند. Captions دقیق، Transcript اصلاح‌شده و کنترل Keyboard برای تجربه لازم‌اند. مالک کامل Query/Package/Retention/VideoObject/Refresh، راهنمای سئو ویدئو است.

Image/Video Sitemap را فقط برای مسئله Discovery بسازید

Sitemap جای HTML و Link graph نیست و Index را تضمین نمی‌کند. وقتی Assetهای مهم از CDN یا JavaScript می‌آیند و Discovery آن‌ها ناقص است، Image sitemap می‌تواند URLهایی را معرفی کند که Google ممکن بود پیدا نکند. برای Video نیز Watch page در <loc> و Thumbnail/Content/Player باید مطابق واقعیت باشند.

• فقط صفحه و Asset عمومی، Canonical، ۲۰۰ و زنده را وارد کنید؛
• URL CDN را ثابت نگه دارید و مالکیت Host اختصاص‌یافته را در Search Console Verify کنید؛
• Sitemap را از Source of Truth بسازید، نه Crawl ناقص Frontend؛
• Desired، Generated، Served و Observed را تطبیق دهید؛
• حذف/انقضای Asset را در Sitemap، Schema و صفحه هم‌زمان به‌روزرسانی کنید؛
• خطای Fetch، MIME، Redirect و Thumbnail را بر اساس Shard/Template هشدار دهید.

ساخت، Eligibility، lastmod، Sharding و Monitoring عمومی در راهنمای نقشه سایت XML تشریح شده است.

Performance گالری را با LCP و هزینه تعامل کنترل کنید

Lazy loading برای اسلایدهای پایین صفحه مفید است؛ برای تصویر اصلی بالای صفحه می‌تواند LCP را عقب بیندازد. راهنمای رسمی گوگل نیز می‌گوید محتوای احتمالاً قابل مشاهده در شروع صفحه را Lazy نکنید. برای Asset اصلی، Discoverability در Parser، Priority و پاسخ Origin/CDN را بررسی کنید؛ برای بقیه، Lazy + Placeholder با ابعاد ثابت.

Budget پذیرش

• تصویر Primary در HTML اولیه، بدون loading=lazy و با Priority سنجیده؛
• width/height یا Aspect ratio برای جلوگیری از CLS؛
• srcset/sizes مطابق Slot و DPR واقعی؛
• Decode و Memory روی Android ضعیف، نه فقط Desktop قدرتمند؛
• Thumbnail request count و Carousel JS bundle دارای Budget؛
• Player/Embed ثالث با Facade و Consent/Privacy کنترل‌شده؛
• Cache hit، Variant key، Purge lag و Stale media پایش‌شده.

فرمت کوچک‌تر لزوماً LCP بهتر نمی‌سازد؛ Queue، Discovery، Render delay و Server response هم دخیل‌اند. روش Field/Lab و p75 در راهنمای Core Web Vitals و RUM آمده است.

گالری باید با Keyboard، Screen reader و Zoom کار کند

W3C WAI برای Carousel بر Structure قابل فهم، عملکرد Keyboard، اعلام تغییر اسلاید، مدیریت Focus و امکان Pause/Resume حرکت خودکار تأکید می‌کند. Accessibility یک لایه جدا پس از SEO نیست؛ Alt، Caption، Controls و State همان اطلاعاتی را می‌سازند که Component قابل فهم شود.

• Previous/Next و Thumbnail picker باید Button یا Link با Name روشن باشند؛
• اسلاید فعلی، تعداد کل و تغییر State به‌طور مناسب اعلام شود؛
• Focus با باز و بسته‌شدن Lightbox گم نشود و Escape خروج دهد؛
• Auto-rotation قابل Pause باشد و با prefers-reduced-motion سازگار شود؛
• Zoom فقط Hover یا Pinch نباشد و محتوای ضروری را مخفی نکند؛
• Caption و Transcript در ترتیب منطقی DOM قرار گیرند؛
• Tap target، Contrast، RTL و ترتیب کلیدها در فارسی تست شوند.

ممیزی گالری را از Crawl تا Outcome لایه‌بندی کنید

برای شروع همه سایت را با یک Metric جمع نکنید. از هر Template و State نمونه بگیرید: محصول تک‌عکس/چندعکس، Variant، محصول ناموجود، پروژه Paginated، Article chart، Video gallery و صفحه دارای خطا.

Search Console Performance را با Search type Image و Appearance ویدئو تفکیک کنید؛ Impression و Click را با Session، Consent و Canonical join آگاهانه دهید. افزایش Gallery interaction الزاماً Conversion نیست: ممکن است کاربر به‌دلیل ابهام بیشتر Zoom کند. برای عکس محصول، نرخ مرجوعی ناشی از رنگ/مقیاس و تماس پیش‌ازخرید نیز Guardrail مهم است.

Workflow انتشار و تغییر گالری

قبل از انتشار

• Search owner، Entity/Variant و نقش هر Asset تصویب شود؛
• Rights، Creator، License، Release و Expiry ثبت شود؛
• Master و Renditionها با Checksum و Policy نسخه‌دار ساخته شوند؛
• Alt/Caption/Transcript با Editorial و Accessibility مرور شود؛
• HTML، URL، MIME، robots، Canonical، OG و Schema تست شوند؛
• Mobile/RTL/Keyboard/Screen reader/slow network و LCP fixture پاس شوند.

پس از انتشار

• صفحه، Asset، Thumbnail و لینک Pagination مستقیم Probe شوند؛
• Rendered HTML و JSON-LD Snapshot ذخیره شود؛
• CDN/Origin errors، Missing asset و Variant mismatch هشدار بگیرند؛
• Search Console و Indexing report پس از تأخیر داده بررسی شوند؛
• Experiment یا Change log، Format/Size/Lazy/Schema را از هم جدا کند؛
• Asset بازنشسته فقط پس از بررسی Usage graph و مسیر Recovery حذف شود.

Runbook خطاهای پرتکرار گالری

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

آیا همه تصاویر گالری باید Alt متفاوت داشته باشند؟

اگر هر تصویر اطلاعات متفاوتی مثل زاویه، رنگ یا جزئیات می‌دهد، Alt نیز باید همان تفاوت مفید را بیان کند. Thumbnail تکراری یا تصویر تزئینی ممکن است Alt خالی یا نام عملکردی بخواهد. هدف، معادل قابل استفاده است نه یکتا‌سازی مصنوعی Keyword.

آیا تصاویر CSS در Google Images ایندکس می‌شوند؟

Google Images در راهنمای جاری خود تصاویر داخل src عنصر img را پشتیبانی و صریحاً CSS image را نامناسب برای Index معرفی می‌کند. تصاویر محتوایی گالری را با HTML استاندارد ارائه کنید؛ CSS را برای تزئین نگه دارید.

برای هر عکس گالری صفحه جدا بسازیم؟

فقط وقتی هر عکس Search intent، Context و ارزش مستقل دارد. در محصول و مقاله معمولاً صفحه اصلی Search owner است و Attachment page کم‌محتوا Cannibalization می‌سازد. تصمیم Keep/Noindex/Redirect را با Inventory و Link/Canonical policy بگیرید.

آیا Image یا Video Sitemap ایندکس را تضمین می‌کند؟

خیر. Sitemap ابزار Discovery است. Asset و صفحه همچنان باید عمومی، قابل Fetch، مرتبط و مطابق الزامات Search باشند. Desired/Generated/Served/Observed را پایش کنید و Sitemap را جای HTML، Context یا Internal link ندانید.

چرا ویدئوی داخل گالری در نتایج Video دیده نمی‌شود؟

ممکن است ویدئو محتوای اصلی صفحه نباشد، Thumbnail یا فایل قابل Fetch نباشد، Metadata تناقض داشته باشد یا صفحه/ویدئو Index نشده باشد. اگر Intent تماشا مستقل است، Watch page واقعی بسازید؛ در غیر این صورت، ویدئو را شاهد مفید صفحه محصول نگه دارید.

منابع و دامنه اعتبار

• Google Image SEO Best Practices برای img src، CSS image، Responsive fallback، URL ثابت، Alt/Context، Sitemap و Preferred image؛
• Google Video SEO Best Practices برای Watch page، Player/Content URL، Thumbnail، Fetch و Monitoring؛
• Google Lazy-loaded Content برای Loading بدون Action، Render test و Pagination پایدار در Infinite scroll؛
• Google Pagination and Incremental Loading برای a href، URL یکتا، Self-canonical و محدودیت Button/Fragment؛
• W3C WAI Carousels Tutorial برای Structure، Keyboard، اعلام تغییر، Focus و Pause/Resume.

جمع‌بندی: گالری سئوشده مجموعه‌ای از فایل‌های کم‌حجم نیست؛ یک قرارداد بین Entity، صفحه، Asset، Render، Search و کاربر است. اول Search owner و Truth را تثبیت کنید، سپس Discovery و Delivery را قابل آزمون سازید. اگر Variant درست، Asset قابل Fetch، Context مفید و تجربه سریع/دسترس‌پذیر نباشد، Alt و Schema بیشتر فقط تناقض را تزئین می‌کنند.