What you'll learn in this article
- How dynamic image assets google ads actually pull images from your landing page, and what the system does and does not let you control
- The exact account profiles where I leave them on and let Google do the work
- When I turn them off and take manual control instead, and why account-level scope forces that choice
- How to add dynamic images google ads through the account-level automated assets settings step by step
- How I review served images so an automated asset never quietly drags a campaign off-brand
The first time I inherited an account already running dynamic image assets google ads, I opened the assets report and found a search ad for a B2B SaaS product showing a stock photo of a smiling family at a kitchen table. Nobody had uploaded that image. Google had pulled it off a testimonial section three scrolls down the landing page, decided it was relevant, and started serving it. That moment is the whole article in one anecdote: dynamic image assets are powerful when the landing page is clean, and a quiet liability when it is not. In this piece I walk through how Google grabs the images, the accounts where I happily leave the feature on, and the cases where I switch it off and control the visuals myself. This is an account-level automated asset, so the on/off decision is bigger than it looks.
How Google pulls images from your site automatically
Mechanically, dynamic image assets google ads work at the account level. You opt in once, and from that point Google identifies and extracts images from each ad's final URL, selecting the ones it judges most relevant to the query. There is no upload step and no per-campaign toggle, it is one switch that applies to every eligible campaign in the account. That account-wide scope is the single most important thing to internalise before enabling it, because it is the reason the feature is either a fast win or an account-wide headache.
The selection is not random scraping. The images Google extracts from the final URL go through a combination of automated and manual quality checks before they are eligible to serve, and they are reviewed for relevance against your keywords, the query, your targeting and the landing page itself. In my experience the system strongly favours images that sit high on the page and have clear product or scene content. If a landing page has no suitable image that clears the quality bar, you simply get no dynamic image asset for that ad, nothing breaks, the ad just runs text-only. Because this is an automated extraction off your own pages, it behaves much like other account-level automated assets in Google Ads: low effort to switch on, but the output is decided by the algorithm rather than by you.
Two control facts shape every decision I make about this feature. First, you cannot choose which specific image gets pulled in advance, Google decides per query and per auction. Second, you can remove any individual served image after the fact, and manual image assets always take priority over dynamic ones when both are eligible for the same ad. Those two facts are the levers I pull throughout the rest of this article.
When I leave dynamic image assets on
My default for a clean e-commerce or service account with strong landing pages is to leave dynamic image assets google ads enabled. When the pages already carry good product photography or genuine lifestyle imagery above the fold, almost any image Google could grab is one I would have been happy to upload anyway. In those accounts the feature is close to free CTR: I get image coverage on ad groups I would never have had time to dress manually, and the images Google selects line up with the query well enough to lift click-through without me touching anything.
Long-tail coverage at zero maintenance
The strongest case for leaving it on is scale. An account with two hundred ad groups is never going to get hand-picked images on every one of them, there is not enough time in the week. Dynamic image assets fill that gap automatically. For the long tail, low-volume ad groups where I would otherwise run plain text, an automatically pulled image that is roughly right beats no image at all. This is the same reasoning I apply to other forms of Google Ads automated assets: let automation cover the breadth I cannot reach by hand, and reserve my manual effort for the campaigns that move the numbers.
Continuity between ad and landing page
There is a subtler benefit I have come to value. Because the image is pulled from the same final URL the headline points to, the visual the user clicks usually matches what they land on. That ad-to-page continuity is something manually uploaded assets can break if you are not careful, you upload a polished shot that no longer matches the current page. With dynamic image assets the image is, by definition, already on the page. The requirement for leaving it on is simply this: every image Google could realistically pull is one I would be comfortable showing. If that holds, on stays on.
When I prefer manual control of the assets
I turn the feature off, or override it, the moment brand precision starts to matter more than coverage. The trigger is almost always the landing page. If the pages carry images I do not want inside an ad, banners with text baked in, watermarked partner logos, generic stock, or off-topic blog imagery, then letting Google choose is a gamble I do not need to take. The smiling-family photo on the B2B SaaS account was exactly this failure mode: a relevant-looking image by Google's logic, completely wrong by mine.
The harder constraint is that dynamic image assets google ads are account-level and therefore all-or-nothing across eligible campaigns. In a single account spanning very different products, an image that is perfect for one line is wrong for another, and there is no per-campaign dynamic toggle to thread that needle. In those mixed accounts I lean on manual control: I upload curated image assets at the campaign or ad group level for the lines that matter, exactly as I would when building any considered visual, the same care I apply to choices like the white background trade-offs across Display and Shopping where the right image is context-dependent rather than universal.
Using priority correctly instead of a hard off
I do not always kill the feature outright. Because manual image assets take priority over dynamic ones whenever both are eligible, I can keep dynamic image assets on as a safety net for the long tail while uploading hand-picked assets to the priority campaigns. Those campaigns then serve my chosen images, and dynamic only fills in where I have left no manual asset. When I do want a hard off, the switch lives in the same place you turn it on, and if I want it gone everywhere I treat it like any other automated extension and disable the automated asset at the account level. The decision rule I follow is blunt: if I trust the pages, I let Google pull; if I need the brand to be exact, I take the wheel.
How to add dynamic images in Google Ads
To add dynamic images google ads there is nothing to upload, you opt in. In your Google Ads account, select the Campaigns icon, open Assets, and find the account-level automated assets settings through the three-dot menu above the assets table. Inside the account-level automated assets settings, locate the Dynamic images control and switch it on. From that point Google begins identifying and extracting eligible images from your landing pages across the account.
Eligibility matters before you bother: the account must have been open for more than 60 days, and it must sit in an eligible vertical, sensitive categories such as gambling and sexual content are excluded. One practical detail I always flag to clients: Google's own guidance is to use image assets and dynamic image assets together rather than treating them as alternatives. Manual assets cover your priority visuals; dynamic fills the rest. The exact opt-in steps, eligibility rules and serving behaviour are documented in Google's official help page on dynamic image assets, which is worth reading once before you enable the feature on a client account.
On cost: there is no extra charge for enabling the feature. If a user clicks a dynamic image asset, you pay the same CPC as a click on one of your text headlines, because the image links to the same landing page as the ad. You are billed on clicks, not on the asset existing, so the real question is never the asset's cost but whether the images Google pulls earn clicks that convert.
Reviewing what Google actually served
Enabling the feature is not the end of the job, it is the start of a light review habit. The risk with any automated asset is that it drifts quietly: an image that was fine in March becomes wrong after the landing page is redesigned in June, and nobody notices because nobody chose that image. So after I switch dynamic image assets google ads on, I check what has served. In the assets table you can filter to the dynamic images that have run and see exactly which visuals Google pulled, and remove any individual one that does not belong.
My cadence is simple. In the first couple of weeks after enabling, I review served dynamic images weekly, that is when the system is exploring your pages most aggressively and most likely to surface something unexpected. After that, a monthly glance is usually enough, with an extra check any time a landing page gets reworked, because a page redesign changes the pool of images Google can draw from. The whole discipline takes minutes and it is the difference between an automated asset that quietly helps and one that quietly embarrasses you.
The takeaway I give every client is the same. Dynamic image assets are a good default for accounts with clean, image-rich landing pages and a long tail you cannot dress by hand. They become a liability the moment the pages contain images you would never choose, and because the switch is account-level, you cannot solve that with a per-campaign tweak, you solve it by uploading manual assets that take priority, or by turning the feature off. Decide based on how much you trust the images already living on your site, then review what serves.