Final URL expansion on Search: leave it on or map URLs by hand?

Final URL expansion is on by default in a lot of Search campaigns, and people keep arguing about whether to leave it that way. The case for it is that Google sends clicks to whichever page it thinks fits the query, which can catch demand you never built a keyword for. The case against is that you lose control of where paid clicks land, and a broad query can end up on a blog post or a careers page that can't convert. I think it depends on the site. With a handful of service pages, I'd turn it off and map keywords to URLs yourself. With a big catalogue and thin keyword coverage, it can pick up real demand, but only if you exclude the pages that shouldn't take paid clicks. Has anyone seen it add conversions rather than just add cost?

I'd push back on splitting this by site size. With a handful of service pages, nearly every URL is one you'd want paid clicks on, so expansion mostly just moves traffic between pages that all convert, and the downside is small. Page mix predicts more than page count does. A ten-page site with a blog, a careers page and a privacy policy carries more risk than a 200-page catalogue where every URL is a product. So work out what share of the indexable URLs can actually take paid clicks, then check the landing page report after a couple of weeks.

Agreed on page mix, and I'd turn it into a test you run before launch. List the URLs you'd happily pay for a click on, then ask whether a query that could plausibly reach the rest would make you wince. If it would for even one page type, like blogs, careers or policy pages, add it to URL exclusions before the campaign goes live.

Doing it up front matters because the landing page report only tells you after the money is spent, and by then the first few weeks of clicks have already gone to the wrong pages. An exclusion list takes a few minutes to set up, so the two-week review can look for surprises you didn't expect instead of cleaning up obvious ones.

A URL exclusion only stops Google from sending traffic to that page. It doesn't stop the query from triggering your ad. So "is dental implants painful" can still show your ad and send the click to a service page you do want, which is usually fine. If the query itself is the problem, you still need a negative keyword, because the two do different jobs.

The match rule matters too. Say a dental clinic adds "contains /careers" to block job pages. That rule also catches /careers-and-training-costs, which might be a page you want paid clicks on. A tighter pattern like "/careers/" avoids that. After launch, read the search terms report for the first week and look at which queries still land on pages you didn't expect.

I'd disagree that "/careers/" is the safer rule. If your careers index lives at /careers with no trailing slash, that pattern misses it entirely, and that's often the exact page you wanted blocked. Look at the real URLs in your sitemap before you pick a match type.

I wouldn't start from the sitemap. It tends to miss old landing pages, orphaned pages, and parameter URLs that still pick up clicks. Pull the URLs that actually got traffic from a past landing page report or your analytics first, then write the rule.

Agreed, and I'd group the data by path before writing any rule. Landing page reports in analytics often show the final URL after redirects, so an old /services-2019 that 301s to /careers will look like a careers hit. Query strings cause trouble too: ?utm and session parameters show up as separate rows, so one page can look like dozens. Strip the parameters, sum the clicks per path, and only then decide which paths get paid clicks.

I'd flip the default and start with an allow list instead of an exclusion list. Write down the paths you'd actually pay for, exclude everything else, and only widen the rule once the data supports it.

The asymmetry is what makes it work. If a good page gets excluded by mistake, you lose some clicks, and you can win them back by widening the rule. If a careers or blog page slips through, it burns money on every click until someone notices. Starting closed is cheaper to fix than starting open.

I'm not convinced starting closed is the cheaper mistake. An over-excluded page doesn't throw an error, it just quietly drops clicks, and nobody ever looks at the queries that never got served. A leaking blog page at least shows up as wasted spend, but a missing service page shows up as nothing at all.

Fair, the silent drop is the real problem with a strict list. My rule of thumb is to exclude a page type only when you'd never pay for a click on it, like blogs, careers, policy or login pages, and leave every commercial page open. If a page is borderline, keep it allowed and deal with the bad queries through negatives, since those show up in the search terms report where you can actually see them. That way the traffic you can't see getting blocked is limited to page types you already decided on, not every service page you forgot to list.