When should you rerun a lookalike search, and how do you show what changed?
Part of Lookalike websites
The short answer
Rerun a lookalike search before each new flight or each quarter, whichever comes first, and sooner when a seed changes owner, topic or address, the brief adds a theme or market, or approved sites lose their selling path. Recheck the seeds first, rerun, then show the client every site added, kept, flagged and removed, each with its reason.
Key takeaways
- The data under a lookalike list moves on its own clocks: Chrome UX Report popularity data monthly, ads.txt files on a seven day default expiry, articles whenever the publisher posts.
- A changed seed is the first refresh trigger to check, because every result inherits its meaning from the seeds.
- Seeds are rechecked before the rerun: kept, re-sectioned, replaced or retired, each with a written reason.
- Sites that do not reappear in a rerun are reviewed, not dropped automatically, and a site that became unsuitable is excluded, not just removed.
- The client sees a short summary of added, kept, flagged and removed sites before the refreshed list is approved.
How often should a lookalike list be refreshed?
A lookalike list is a snapshot of a search: these seeds, this index of candidate sites, these checks, on this date. Each part changes at its own pace, so a list that was right in spring can be wrong by the holidays without anyone touching it.The useful question is how fast the evidence behind the list goes stale.
| Evidence | How it changes, per its source | What it means for a refresh |
|---|---|---|
| Audience popularity by country | "CrUX data on BigQuery is released on the second Tuesday of the following month" | Market fit can shift month to month |
| Authorized sellers (ads.txt) | Without cache directives, consumers "should default to an expiry of 7 days" | Selling paths can change within a flight |
| Site content | A sitemap's lastmod is "the date of last modification of the page"; changefreq is "a hint and not a command" | Read recent articles again; a site's stated schedule proves little |
| Content categories | In IAB Tech Lab's taxonomy versioning, "major version numbers represent breaking changes" | Recheck category labels when the taxonomy version changes |
| The client's seeds | Changes whenever the brief, the product or the client's favorites change | Recheck seeds at the start of every refresh |
A refresh is different from routine monitoring of an approved list. Monitoring rechecks the sites already chosen; a refresh reruns the search from the seeds, which can find sites that did not exist or did not qualify last time. The lookalike websites hub describes the original search; this page is about running it again.
What triggers an early lookalike refresh?
Some changes cannot wait for the next quarter. The first to watch for is a seed that is no longer the site the client chose. Google's spam policies (opens in a new tab) (last updated August 28, 2026) describe expired domain abuse, "where an expired domain name is purchased and repurposed primarily to manipulate search rankings," with examples such as "Casino-related content on a former elementary school site." A seed that changes hands this way drags the whole search toward its new content.
Early refresh triggers
- A seed's ads.txt shows a new OWNERDOMAIN, which the ads.txt 1.1 spec defines as "the business domain of the business entity that owns the domain/site/app".
- A seed redirects to another domain, or its address no longer loads.
- A seed's recent articles have moved to a different subject, tone or depth from the one the client liked.
- The brief adds a theme, a product line, a market or a language that the original seeds do not cover.
- The client names a new favorite site or withdraws one of the original seeds.
- Several approved sites lose their authorized seller entries or stop carrying advertising.
- A new major version of the content taxonomy the plan uses is adopted by the team's buying platforms.
Ownership changes deserve a direct look, because they can be quiet. The ads.txt 1.1 specification on IAB Tech Lab's GitHub (opens in a new tab) also defines MANAGERDOMAIN as "the business domain of a primary or exclusive monetization partner of the publishers inventory." A new value in either field is a reason to read the seed again. The guide to who owns a website covers the full ownership check.
How do you handle seeds that changed?
Recheck the seeds before rerunning anything. A rerun from a changed seed produces a confident list of the wrong sites, and the client will not see the cause unless the planner looks first.
| What changed | How it shows up | Decision | What the client hears |
|---|---|---|---|
| Nothing material | Recent articles still match the theme and depth | Keep | Seed confirmed, with the date read |
| One section drifted, one still fits | The site added unrelated sections | Re-section: seed with the fitting section | Seed narrowed to the section they value |
| The subject or quality changed | Thin, templated or off theme articles replaced the old ones | Replace with a site that shows the original theme | Old seed retired, replacement proposed for approval |
| The site is gone or changed hands | Redirect, dead address or new owner with new content | Retire, and exclude it if the new content is unsuitable | Seed retired, with the evidence |
Recheck a seed in five steps
- Open the seed. Confirm the address loads without a redirect to another domain.
- Read five recent articles. Write one sentence on each and compare them with the reason the client gave for the seed.
- Read its ads.txt. Compare OWNERDOMAIN and MANAGERDOMAIN with the values recorded last time.
- Decide. Choose keep, re-section, replace or retire, and write the reason in one line.
- Ask the client about any replacement. A new seed changes the search, so the client approves it before the rerun.
Replacement seeds follow the same rules as the original choice, covered in the guide to seed site selection. If the client's favorite site no longer exists, ask what they valued in it and find a seed that shows that quality today.
How do you show refresh changes to a client?
A client can approve a refreshed list faster when it can see the difference at a glance. Google Ads uses the same idea in its date range comparisons (opens in a new tab), which expand a column into the current range, the previous range, "the numerical change between the 2 date ranges, and the percentage change." A refresh summary does the same for sites: last list, new list, and what moved.
| Group | What goes in it | Reason shown |
|---|---|---|
| Added | Sites new to the list that passed every check | Which seed theme each matches, with two matching articles |
| Kept | Sites on the old and new lists | None needed beyond the count |
| Flagged | Sites kept but due for a closer review | The specific change, such as a new seller entry |
| Removed | Sites taken off the list | The reason in one line, such as a change of subject |
| Seeds | Each seed and its decision | Keep, re-section, replace or retire, with the date read |
The summary is about the search, not about bookkeeping. Version names, change logs and rollback belong to site list version control, which keeps the record of each approved list; the refresh summary is the short explanation a client reads before approving the next one.
Should old sites be removed on refresh?
Not just because they failed to reappear. A rerun can rank a good site lower because new candidates arrived, or miss it because a sample of its articles happened to fall on other subjects. Delivery data is a weak tiebreaker at low volume: Google's Where ads showed report (opens in a new tab) warns that its performance data "is generally not statistically significant" when impressions are sparse, and says not to use it "as an exhaustive list of placements for your ads."
Display & Video 360 makes the same split in its channels (opens in a new tab), which can serve as "a preset, targetable list of brand-appropriate publishers" or "a preset, excludable list of publishers where you don't want your ads to serve." At refresh time, sort each departing site into one of two groups: no longer a fit, which only leaves the inclusion list, or no longer acceptable, which moves to the exclusion list.
How does PlacementGraph support a lookalike refresh?
What does a lookalike refresh look like on a real brief?
Fictional example
A fictional jigsaw puzzle maker in the Dakotas
An unnamed Fargo maker of wooden jigsaw puzzles ran a spring lookalike list for North Dakota and South Dakota from three seeds: a puzzle review blog, a family game night site and a crafts magazine's puzzle column. Before the holiday flight, the planner runs a refresh.
The seed check finds trouble. The puzzle review blog now carries a new OWNERDOMAIN, and its recent posts are coupon roundups for unrelated products. It is retired and excluded, and the client approves a replacement: a puzzle community site with detailed reviews. The crafts magazine has added home decor sections, so its seed is narrowed to the puzzle column.
The rerun adds eleven sites, including a Sioux Falls family activities site with a weekly puzzle feature. Thirty sites are kept, two are flagged for new seller entries and four are removed: three no longer cover puzzles and one changed hands. The client gets a one page summary with these counts and reasons, then approves the new list.
Frequently asked questions
Does a refreshed list need fresh client approval?
Yes. A refresh can add sites the client has never seen and retire seeds the client chose, so the new list goes through the same approval as the first one. The summary of added, kept, flagged and removed sites keeps that approval short, because the client only needs to read what changed.
Can a lookalike refresh run in the middle of a flight?
It can when an early trigger fires, such as a seed changing hands. Apply removals and exclusions at once, since they protect the brand. Hold additions until the client approves them, and add them to the running campaign in one batch so delivery reports stay readable.
What if the refresh finds fewer sites than the first run?
Read the removed and missing sites before reacting. A smaller list can be correct: some sites changed subject or stopped selling. Do not pad the list with weaker matches to reach the old count. If reach is the concern, add a seed for a theme the client values rather than loosening the checks.
Who decides when a seed should be replaced?
The planner proposes and the client decides. The planner has the evidence: the recent articles, the ads.txt fields and the redirect history. The client knows why the seed mattered. A replacement seed changes the search, so swap one only with the client's agreement in writing.
Sources
- CrUX on BigQuery (opens in a new tab)Chrome for Developers
- ads.txt Specification Version 1.1 (opens in a new tab)IAB Tech Lab (GitHub)
- Sitemaps XML format (opens in a new tab)sitemaps.org
- IAB Tech Lab Taxonomies (opens in a new tab)IAB Tech Lab (GitHub)
- Spam policies for Google web search (last updated August 28, 2026) (opens in a new tab)Google Search Central
- Compare and track your ads' performance over time (opens in a new tab)Google Ads Help
- About the "Where ads showed" report (opens in a new tab)Google Ads Help
- Exclude specific webpages and videos (opens in a new tab)Google Ads Help
- About channels (opens in a new tab)Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.