Website image formats: check the fallback

Website image formats deserve an acceptance check when a developer changes how your product photographs or portfolio images reach visitors. A smaller file and a successful preview are useful evidence, but neither tells you whether the page still gives Google a supported image source. Before accepting the change, ask your developer to show the actual page output, its fallback image and the checks performed on important pages.

This matters when an image plugin, hosting service or custom website update changes the files your pages serve. It does not mean every website needs a new image pipeline. If you are choosing a supplier or approving an optimisation proposal, the useful decision is whether the proposed change preserves image delivery and discovery while meeting an agreed performance or quality need.

What Google's supported formats tell you

Google's image SEO guidance lists BMP, GIF, JPEG, PNG, WebP, SVG and AVIF as supported image formats. JPEG XL is not in that list. That is a reason to check an implementation that proposes JPEG XL as its only image source. It is not evidence that Google has just changed its policy, or that a particular site's traffic has fallen.

The same guidance explains that Google discovers images through the src attribute of an HTML img element. It recommends providing a fallback img element with a src attribute when using a picture element. These names describe the page markup your developer controls. You do not need to write that markup to ask for evidence of the result.

A picture element can offer alternative versions of an image. The fallback gives the page an ordinary image source as well. A preview may show one of the alternatives while leaving a problem with the fallback undiscovered. Ask which file the fallback points to and whether that file is available in a supported format. A claim that "the browser displays it" leaves that separate question unanswered.

Supported format is only one condition. Google's guidance also discusses image accessibility, relevant page content and descriptive text. A valid image source does not guarantee indexing, a place in Google Images or Discover, a ranking or an enquiry. Keep technical acceptance separate from any later assessment of search results.

Decide what the change needs to improve

Start with the reason for the proposal. Perhaps a product page is delivering unnecessarily large photographs, or a portfolio image loses useful detail after compression. Ask the supplier to compare the current and proposed delivery on representative pages, using the same conditions, and explain the effect on visual quality and loading. Do not accept a percentage improvement without knowing what was measured.

A supported format such as WebP or AVIF may be an option, but the format name alone does not establish the best result for every image. The developer still needs to consider the image content, dimensions, quality settings and how the site generates and serves variants. Keeping the present arrangement can be reasonable when it already meets the need and the proposed change adds maintenance without a demonstrated benefit.

If the supplier proposes an additional format for some browsers, ask who maintains the alternatives and fallback after deployment. Extra versions create more output to check. The business should understand whether a later image upload or plugin update follows the same rules as the sample the supplier demonstrated.

Agree the acceptance scope before the change. For a product catalogue, that may include a product detail page, a category page and a newly uploaded photograph. For a portfolio, it may include a project page and its listing card. Choose examples that exercise different templates or delivery paths rather than assuming one attractive homepage proves the whole site.

A product image that passes the preview and fails acceptance

Consider a fictional furniture retailer approving a change to its product photography. Its developer proposes alternative image files to reduce delivery size while preserving enough detail for shoppers to inspect the finish. The retailer agrees to assess the product page, its category card and the upload process for a new photograph in a test environment.

The developer's preview looks correct. On the product page, however, the fallback img source still points to an old JPEG location that the new process no longer creates. The developer checks that exact URL and finds the image unavailable. The browser used for the preview had selected an alternative file, so the screenshot did not expose the missing fallback.

The retailer holds acceptance. It does not infer that Google has already dropped the product image, and it does not ask the developer to change every image format again. The concrete defect is the unavailable fallback. The developer corrects the generated markup and delivery process so that the fallback points to an available supported image of the same product.

The team repeats the check on the actual generated page. It confirms the fallback file is accessible, shows the intended product and is referenced by the page. It then checks the category card and uploads a fresh test photograph through the normal publishing process. This last step matters because a manually repaired sample would not prove that the next upload works.

The developer also compares the proposed output with the agreed visual quality and delivery measures. If the image now works but its finish detail is unacceptable, the change still fails the retailer's requirements. The developer can adjust the generation settings and repeat the comparison, or the retailer can keep the previous arrangement. Resolving a markup problem does not justify accepting a worse product image.

In this fictional example, the corrected process passes both the delivery checks and the retailer's quality requirements. The retailer approves a controlled release, with the previous arrangement available for rollback. After release, the developer checks the affected live templates and a newly published image. A failure on the live site would trigger correction or rollback under the agreed change plan. It would not become an accepted limitation simply because the test environment passed.

Make the handover useful for the next change

Ask for a short record of the pages checked, the image URLs and formats involved, the fallback result and any remaining exclusions. Keep the comparison evidence with it. That gives the next developer enough context to understand what was accepted without treating a screenshot as a complete technical handover.

Also identify who owns image generation and delivery. A website developer may control the markup while a plugin or image service controls the files. If either side changes, someone must check that their outputs still agree. A documented dependency is more useful than a general promise that the site is "SEO friendly".

The image should remain meaningful in its page context. Ask the editor to check that the photograph matches the product or project, that surrounding copy explains it and that alternative text describes its purpose appropriately. Technical file checks and editorial checks address different failure modes. Neither supplies permission to use an image or proves the claims made beside it.

Your wider website handover and owner checks should cover how content changes after launch, who responds to a fault and what is included in ongoing support. For a site connected to a catalogue or other business system, include the process that imports or replaces images. A manual upload check alone may miss a separate automated path.

Bring an actual page to the supplier discussion

Before approving an image optimisation change, choose a representative page and ask the supplier to explain its current source, proposed alternatives and fallback. Agree the quality and delivery result you need, then require evidence from the generated output and the live release. If the supplier cannot explain which part it controls, resolve that responsibility before accepting the work.

Web development support can include reviewing how image delivery fits the website's templates, content workflow and connected systems under an agreed scope. A discussion should establish the problem and the checks needed before committing to a particular format or rebuild.

Discuss your website's image delivery and acceptance checks. Bring the page URL, the proposed change and any supplier comparison. The next decision is whether that change meets a defined need and can be maintained when your next image is published.