How to Make Website Thumbnails for an Indian Wedding Vendor Directory

A useful wedding vendor thumbnail starts with a photograph the vendor is authorized to share, cropped for the directory’s actual card layout, and delivered at a size appropriate for the visitor’s screen. Keep the original, preserve creator and credit details, and show the image with a standard HTML <img> element, responsive variants, and concise alt text.

There is no universal pixel dimension or file-size target for every directory. Choose the card’s proportions from your design, export versions that suit its rendered sizes, and check the real page at phone, tablet, and desktop widths.

1. Request and organize vendor photographs

Ask each vendor for a photograph that represents the service or work shown in their listing: for example, a venue, floral arrangement, bridal makeup, or a real wedding setup. Ask them to provide an image they are authorized to have displayed in your directory. A vendor sending you a file does not by itself establish who owns the photograph or what uses are permitted.

Keep the original file as your source asset. Store it separately from the derivatives used on the site, and record the vendor, source filename, creator if known, requested credit, and the use the vendor authorized. This makes later recropping and rights questions easier to handle.

2. Decide the card layout before cropping

Set the card design first. Decide how wide the thumbnail appears at each responsive layout and whether the design uses a fixed aspect ratio. Then choose a crop that keeps the important subject visible at those sizes. A tall portrait, a wide venue photograph, and a close-up of jewelry will not all have the same useful focal area.

Use a consistent card shape across the directory so the listing grid stays orderly.
Choose a focal crop that still represents the vendor’s work when reduced to card size.
Check the crop at phone, tablet, and desktop widths; a subject that looks centered in one crop may be lost in another.
Keep the original so you can create a different crop later without repeatedly editing an already reduced image.

Do not treat one pixel dimension as a universal rule. The right export dimensions depend on the rendered card, the layout, and the image pipeline. Google’s guidance recommends responsive image techniques and optimization, but does not set a universal size for this directory use case. Google Search Central’s image guidance explains image discovery and responsive markup.

3. Export responsive image variants

Rather than sending a large original to every visitor, create suitable variants for the sizes your layout uses. Use srcset and sizes when the browser can choose among width variants, or use <picture> when you need format-specific sources. Retain an ordinary img with a src fallback.

<img
  src="/images/vendors/mehndi-artist-640.jpg"
  srcset="
    /images/vendors/mehndi-artist-320.jpg 320w,
    /images/vendors/mehndi-artist-640.jpg 640w,
    /images/vendors/mehndi-artist-960.jpg 960w
  "
  sizes="(max-width: 600px) 90vw, (max-width: 1000px) 45vw, 320px"
  width="640"
  height="480"
  alt="Mehndi artist applying bridal henna at a wedding"
>

The values in this example illustrate markup only. Replace the paths and widths with files your image pipeline actually generates, and make sizes reflect the card’s real CSS layout. The width and height attributes should reflect the image’s intrinsic dimensions so the browser can reserve space as it loads.

For a format-specific source, keep the fallback inside the picture element:

<picture>
  <source
    type="image/avif"
    srcset="/images/vendors/mehndi-artist-320.avif 320w,
            /images/vendors/mehndi-artist-640.avif 640w"
    sizes="(max-width: 600px) 90vw, 320px"
  >
  <source
    type="image/webp"
    srcset="/images/vendors/mehndi-artist-320.webp 320w,
            /images/vendors/mehndi-artist-640.webp 640w"
    sizes="(max-width: 600px) 90vw, 320px"
  >
  <img
    src="/images/vendors/mehndi-artist-640.jpg"
    width="640"
    height="480"
    alt="Mehndi artist applying bridal henna at a wedding"
  >
</picture>

Choose formats and compression by comparing visual quality at the rendered card size, transfer size, device coverage, and compatibility with your delivery pipeline. Google lists BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF as supported when referenced from an img src; make sure each filename extension matches the file’s actual format. Do not assume one format or compression setting is best for every source photograph.

4. Use crawlable markup and descriptive context

Put directory photographs in HTML image markup rather than relying only on CSS backgrounds. Google says it finds images from img src and does not index CSS background images as images. Give the image concise alt text that describes what it actually shows. Nearby text such as the vendor’s name or a caption can provide additional context.

Alt text should describe the photograph’s visible content, not repeat a list of search terms. If the photograph is decorative and adds no information beyond nearby text, avoid adding a redundant description. For a vendor card, the vendor name is usually already visible as text; describe the image itself in the alt attribute.

5. Keep image rights information with the asset

For each source image, record who created it, who owns it if known, what credit was requested, and what use was authorized. Keep these details in your asset record or content system so they survive recrops and format conversions. Google documents structured data and IPTC metadata as ways to communicate creator, credit, copyright, and license details, and recommends retaining important rights and identification metadata where possible. See Google’s image license metadata documentation.

Search documentation describes metadata practices; it does not decide whether a particular image use complies with Indian copyright or privacy law. If an image raises a rights or consent question, resolve that separately before publishing it.

6. Make public images discoverable when search visibility matters

If you want search engines to discover a listing image, the page and image file need to be publicly accessible and searchable. An image sitemap can help expose image URLs that might otherwise be missed, including images hosted on a CDN. Public access and correct markup make crawling possible, but indexing is not immediate or guaranteed. Google’s image SEO guidance and image search help describe these limits.

7. Review the directory before publishing

Confirm that the vendor supplied or cleared the photograph for directory display.
Check the crop in the actual card at each responsive layout.
Verify that every responsive candidate exists and that srcset, sizes, and any picture sources match the generated files.
Confirm the img fallback works and the extension matches the image format.
Write alt text from the visible image content and retain useful nearby vendor context.
Keep creator, credit, copyright, and authorization details alongside the source asset.
If search discovery is a goal, check that the page and image URL are publicly accessible; consider an image sitemap for URLs that may otherwise be missed.

8. Troubleshooting common thumbnail problems

Problem	Likely cause	What to check or fix
The wrong size loads on a phone or desktop	`sizes` does not describe the rendered card width, or a `srcset` candidate is missing.	Compare the real CSS layout to the `sizes` expression and verify every candidate URL.
A thumbnail is blurry	The selected variant is too small for its rendered size or display density.	Provide a suitable larger variant and check it at the card’s actual display size. Retina displays may need a higher-resolution source.
The subject is cut off	A single crop does not suit the image or responsive card shape.	Revisit the focal crop, or provide art-directed sources with `picture` if the composition needs to change at a breakpoint.
The image does not load	A path is incorrect, a derivative was not generated, or the server returns the wrong file.	Open each candidate URL directly, confirm the server response and content type, and ensure the fallback points to an existing image.
A format-specific image fails for some visitors	The browser or delivery path does not support that source, or the file extension does not match the bytes.	Keep a supported fallback in `img src`, verify the files, and check that source type and extension are correct.
The page layout jumps as images load	The browser does not know the image dimensions before loading.	Set accurate `width` and `height` attributes or reserve the card’s aspect ratio in CSS.
The image is not appearing in search	The page or asset may not be crawlable, or indexing may not have happened.	Check public accessibility, standard `img` markup, and sitemap coverage. Discovery does not guarantee indexing.
The rights or credit details were lost after export	Metadata was stripped or not copied into the content record.	Retain rights details in the asset system and, where appropriate, structured data or IPTC metadata.

9. Performance, reliability, and cost

Use variants that fit the rendered layout so small cards do not routinely transfer the full source photograph. Measure your actual pages and balance clarity against transfer size; the cited guidance does not establish a universal byte target. Responsive image markup gives browsers a choice among versions, but only if the candidate files exist and the sizes description matches the layout.

Keep the original and generate derivatives reproducibly. This makes it possible to rebuild outputs after changing the card design or image pipeline. Check the fallback and every referenced candidate, and avoid publishing a listing whose image path points to an asset that was never generated.

The research sources do not establish a standard image-hosting cost, storage price, or performance benchmark for this use case. Estimate cost from your own storage and delivery provider’s pricing, image count, file sizes, and traffic. Compare formats and export settings using representative vendor photos rather than relying on a single assumed best setting.

10. Capture consistent vendor-page previews

If you need a repeatable preview of how public vendor pages look in a directory or review workflow, ScreenshotNeo is a website screenshot API and MCP server. It can capture a page as PNG, JPEG, WebP, or PDF. A screenshot is useful for visual review; it does not replace the directory’s real responsive image markup, image optimization, or rights records.

11. FAQ

Should each vendor card use a different aspect ratio?

A consistent card shape generally makes the directory easier to scan. Choose a crop for each photograph that works within that shape, and check whether unusual compositions need a different focal crop.

Does a public image URL guarantee it will appear in Google Images?

No. Public accessibility and crawlable markup help discovery, but indexing is not immediate or guaranteed.

Can a CSS background replace an image element for a listing photo?

Use an HTML img for a vendor photograph you want search engines to discover. Google’s image guidance says it finds images from img src and does not index CSS background images as images.

Or skip the browser setup

Capture a vendor page preview with one API call. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers report the page verdict and billing status.
An MCP server lets AI agents using Claude, Cursor, or another MCP client take screenshots, get page information, and capture PDFs.
The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 shots; every feature is on every plan.