An AI website builder can lay out a clean homepage in seconds: a hero band, an about block, a three-up services grid, a testimonial row, a footer. Then it hands you a page full of grey rectangles where the images should be. The structure is done; the visuals are missing, and now you are clicking through each empty box trying to find something that fits, looks right, and is actually safe to publish.
This post looks at that gap from the builder's side. If a generator already knows it just created a "hero for a dental clinic" or an "about section for a freelance photographer," it has almost everything it needs to fetch a matching image on its own, no human curating slot by slot. The piece that makes that possible is structured image data.
Scope. This article describes a vendor-neutral builder pattern. It does not document a live Picdrome API. Use an image source you are authorized to access, normalize its records inside your own adapter, and treat the Picdrome developer hub as a design guide only.
Why builders nail the layout but leave the images blank
Generating layout is a text problem. A model can reason about sections, copy, spacing, and component order because those live in code and content it already understands. Picking an image is a different kind of problem: the builder has to find a real asset, decide it suits the section, confirm it is licensed for the site, and attach the right metadata. Most builders stop at the placeholder because they have no reliable source to pull from at generation time.
The result is a familiar handoff. The tool produces a polished skeleton, then the person inherits the tedious part: opening a stock site in another tab, searching by vague keywords, downloading, cropping, re-uploading, and writing alt text for every slot. For a five-section page that is a lot of manual work tacked onto an "automated" build.
The fix is not smarter image generation inside the builder. It is giving the builder a library it can query in the same vocabulary it already uses to describe the page.
What a builder actually needs to know to pick an image
When a generator creates a section, it already holds the three facts that determine which image belongs there. Those map cleanly onto how Picdrome organizes its library:
- Where it goes (the section). Hero, about, services, testimonial, feature, footer. This drives shape, focal point, and how much quiet space the image needs so text stays readable on top.
- Who it's for (the business type). A bakery, a law firm, a SaaS dashboard product, a yoga studio. This narrows subject matter so the picture reads as relevant rather than generic.
- What style it is. Bright and minimal, warm and editorial, dark and technical. This keeps the image consistent with the brand and the rest of the page.
These what / when / who facets are the design model described in Picdrome's guides. In an adapter that implements them, a builder that has decided "this is a services grid for a moving company in a clean, friendly style," it can pass those exact facets to the library and get back candidates that already fit the slot instead of guessing from a keyword search.
If you want the deeper field-by-field view of how this metadata is shaped, see what image metadata matters when building pages programmatically.
How structured metadata lets a generator self-serve
A plain stock search returns whatever matches a word. Structured, use-case-tagged metadata returns images filtered by the role they play on a page, which is what a builder needs to make an unattended choice.
Here is the difference in practice:
| Keyword stock search | Use-case-tagged retrieval | |
|---|---|---|
| Query input | A guessed phrase ("happy team office") | Section + business type + style |
| What comes back | Anything matching the words | Images scoped to that page role |
| Sizing/crop fit | Unknown until you open it | Aspect and focal point tagged for the section |
| Text overlay safety | You eyeball it | Quiet-space signal travels with the image |
| Caption/credit | You write it from scratch | alt_text and license returned with the asset |
| Automatable | Needs a human in the loop | Builder can place it directly |
Once the data is shaped this way, a builder can treat "fill this hero" as a single request rather than a research task. For the request side specifically, searching images by business type and page section via API covers how those facets become query parameters.
A typical slot-to-image flow
Walking one section end to end shows where each field lands:
- The builder finishes a slot. It generates an about section for a "boutique accounting firm, calm and professional style" and marks the image placeholder with that context.
- It forms a request. Section = about, business type = professional services / accounting, style = calm-professional. Those map straight to the library's facets.
- The library returns candidates with their metadata. Each result arrives with its image URL, an
alt_textvalue, and alicensefield, plus the AI-generated disclosure. - The builder places the image and carries the fields through. The image goes in the slot. The returned
alt_textbecomes the page's alt attribute so the section stays accessible. Thelicensevalue is preserved and linked to the Picdrome Image License rather than dropped. - It moves to the next slot and repeats, so a full page can be populated in one pass.
The important habit is that alt_text and license are not throwaway response fields. They are meant to travel into the generated page. Carrying them through is what turns a fetched image into a finished, accessible, properly-attributed section.
Keeping it honest: what travels with each image
Two things must ride along with every image a builder places, and they are the parts an automated flow most often forgets.
Licensing. Picdrome images are free to use for personal and commercial website projects, subject to the Picdrome license terms. That is the accurate way to describe them. They are not "public domain," not "CC0," and not "royalty-free" or "unrestricted." Fetching an image through an API does not grant it any special or expanded rights; the same terms apply whether a person or an agent retrieved it. A builder should keep the returned license value with the asset and point to the Picdrome Image License so whoever ships the site knows the conditions. This is general information, not legal advice; the license page is the source of truth.
AI disclosure. Every returned image is AI-generated, and that fact comes back in the response. A builder must not present a generated image as something it isn't. An AI-generated person is not a real customer, a real team member, or a real testimonial, and the generated page should never frame them that way. Use these images for atmosphere, illustration, and sections where a representative scene is fine; do not wire them into "meet the team" bios or quoted reviews that imply a real, identifiable person endorsed the business.
Getting these two fields right is also what keeps the automation trustworthy. A builder that quietly strips licensing and disclosure isn't saving the user work; it is handing them a compliance problem later.
Does this make sites look better or convert more?
It is worth being plain here. Pulling in tagged images removes manual steps and gives each section a contextually relevant starting image instead of a grey box. That is a workflow benefit. It is not a guarantee of a better-looking or higher-converting site. Page performance depends on copy, design, offer, audience, and much more than the image source. Treat use-case retrieval as a way to finish pages faster and more consistently, and keep human judgment for the cases where a section needs a specific, deliberate visual.
Where to go next
If you are building or extending an AI website builder or agent:
- Read the Picdrome developer hub for the vendor-neutral image-record and fallback design.
- Use the search-by-use-case design guide to map section and business context into your own adapter.
- Validate source access, license terms, failure handling, and human review before enabling automated publishing.
For the wider picture of automated image sourcing, including non-builder use cases, this post is one spoke off the pillar on how to add website images automatically with an image API.
In Plain English
This is about letting an AI website builder use an approved image source instead of leaving empty placeholders. The builder already knows the section, business type, and style, so your adapter can request candidates and normalize them without a person hunting slot by slot. Carry alt_text, source, AI-generated provenance, and a current license record into the page. Never present a generated person as a real customer or team member, and block publishing when the intended use or attribution rule is unclear. Start with the vendor-neutral integration design guide.