Google Ads broken-link checks in Slack with destination findings, scope, and repair ownership

Define the destination-checking job in terms of the customer journey

An advertising destination is where a person is intended to arrive after interacting with an ad or linked asset. The practical checking job is to establish whether that intended journey has a known problem, identify the affected advertising context, and give the responsible person enough evidence to investigate. A report titled “broken links” can otherwise hide several different questions. A missing page, an unsuitable redirect, an inaccessible offer, and a provider-reported destination issue all need attention, but they are not the same observation.

Begin with the user's purpose. An operator preparing a promotion may want to inspect known destination findings before enabling the offer. A site owner after a release may want to test whether particular routes still work. An agency reviewing a client account may want to find destination-related policy issues across ads and assets. The ppctor Links tool directly supports the provider-findings review. It should not be presented as a substitute for the site owner's live acceptance testing after a deployment.

The best answer connects evidence to a next task. If Google reports a destination-related policy topic on an ad, identify that ad's campaign and group and preserve the topic's meaning. If a live page test shows a failed route, record the route and test context. If both observations exist, explain them separately. A person can then decide whether to repair the page, correct the ad's destination, inspect the provider state, or perform more investigation. The output becomes a work item rather than a vague warning.

Keep the business goal visible throughout the incident. A service campaign needs a usable booking journey; a retailer needs the correct product or collection destination; a sitelink needs the page promised by its label. A technically successful response can still lead to the wrong experience. Conversely, an old provider finding can remain visible after a site repair until its relevant state changes. Describing the intended journey helps the reader understand why a separate technical check and provider follow-up may both be necessary.

Understand that Links reads Google's findings rather than crawling pages

The current Links implementation retrieves destination-related policy topics from Google Ads. It does not open each advertiser landing page and test it directly. The report therefore describes what the provider has noticed and published by the time of the read. A page that fails immediately after a website release may not yet appear. A page repaired recently may still need a provider-state check. These timing boundaries are central to interpreting the result, rather than minor qualifications beneath an all-clear headline.

Google's destination requirements distinguish page functionality, destination consistency, crawlability, and accessibility. A destination-related finding can therefore concern more than a missing page. Read the reported topic and investigate its actual meaning instead of translating every issue into “404.” See Google's destination requirements.

This design makes a focused account review possible without sending a large collection of requests to the advertiser's website. It also means the report cannot claim current response times, current checkout behavior, or real-time uptime. Those are different tests with different evidence. A fast provider read is useful when the user asks which advertising destinations have known issues. It remains incomplete when the user asks whether a page changed a few minutes ago is working for customers right now.

Use clear wording for a clean result: no destination-related findings were returned in the successfully read surfaces. That wording preserves both the evidence source and its coverage. It does not mean every page has just been opened, every redirect inspected, and every customer journey completed. An owner can still request a specific investigation after a clean provider review. The important distinction is that the second investigation answers another question; it does not invalidate the first report's limited but useful evidence.

Read the coverage across ads, account assets, and asset-group associations

The current tool reads three surfaces: ads, assets at account level, and asset-group asset associations. It selects destination-related policy topics from each surface. The ad read retains campaign and ad-group context and excludes removed parents and ads. The asset-group read retains campaign and asset-group context and excludes removed parents. The account asset read helps cover assets such as sitelinks that may be attached at different levels. This is broader than checking responsive search ads alone.

Those surfaces represent different kinds of evidence. An ad finding is attached to that ad context. An account asset finding describes the asset itself. An asset-group association finding describes its group context. A combined count is a count of returned findings under those structures, not necessarily a count of unique destination URLs. The same page can be referenced by several advertising entities. Avoid telling the user that ten findings means ten distinct broken pages unless a separate URL-level analysis establishes that fact.

The reads settle independently so that one failed surface does not erase the successful evidence from the others. The report records which surfaces could not be read and excludes their unknown findings from the returned count. A partial result should be described as partial. No returned issues among ads and assets cannot establish that the unread asset-group surface is clean. When the user needs a complete launch review, finishing that unresolved read remains part of the work.

A focused question may still require additional context beyond the deterministic result. The current finding includes a readable target reference, parent context when available, and the provider topic, but it is not a complete URL inventory. If the user asks for the actual final URL of a selected ad, the assistant needs an applicable supported read for that field. The extra request should be driven by the question rather than an assumption that the first output already contains every destination detail.

Interpret configuration status without claiming actual delivery

For ads, the current tool treats the context as enabled only when the ad, ad group, and campaign are all enabled. For asset-group findings, it checks the group and campaign status. This is useful prioritization because an enabled child inside a paused parent does not have the same immediate intended-use context as a fully enabled chain. The status describes configuration. It does not prove that the affected entity is currently receiving impressions or spending money, particularly when a policy finding restricts delivery.

Account-level assets have an additional limitation: the asset resource does not supply an independent enabled-or-paused status matching its attachment relationships. The current result puts those findings in its enabled-side list without resolving every attachment's serving state. Treat them as assets needing attachment-context review, not confirmed live spending targets. This boundary matters for sitelinks reused across campaigns. An account asset can be worth repairing even when its current business exposure has not been established.

Paused findings remain useful. A business may have stopped using an offer when the destination failed and never repaired it. A seasonal campaign may be due for reuse. A paused group can contain a known problem that the owner should inspect before enablement. The report should keep those findings separate from the intended active population, rather than either ignoring them or describing all returned issues as ongoing exposure. Their relevance depends on the future plan, which the owner can supply.

Historical performance provides another distinct view. A campaign may have spent during the selected report period even though it is paused now. That cost can help explain past importance but does not establish present delivery. A current enabled state can indicate intended use without proving current cost. Keep the time and configuration context intact when combining these views. The reader needs to know whether a statement concerns observed activity, current settings, or a planned launch.

Identify the advertising target with the correct parent context

A readable target reference should tell the account operator which entity needs review. For an ad, campaign and ad-group names provide the surrounding context. A headline or ad name can help distinguish the creative. For an asset-group association, the campaign and asset-group names locate the finding. For an account asset, its sitelink text or asset name may be the initial reference, with attachment context requiring further inspection when the action depends on it.

Do not mistake a label for a unique identity. Several ads can have the same opening headline, and several assets can use the same visible text. A user-facing report can remain readable while the framework resolves exact provider identities behind the scenes. If the available reference is ambiguous, ask for the smallest clarification needed before preparing a change. Showing raw identifiers to a normal user is not a replacement for a comprehensible target and its correct parents.

Keep parent terminology accurate. Campaigns contain ad groups for relevant campaign structures; Performance Max uses asset groups. An existing ad group should not be displayed as though another ad group were its parent. An asset does not acquire a guessed parent just because its name resembles a campaign name. The context shown in the proposal must come from the resolved relationship. This matters most when a follow-up says “change that one,” because the assistant must preserve the intended target across the conversation.

Use the target reference to make the handoff precise. The site owner needs to know which intended destination is affected; the account operator needs to know which advertising entity uses it. These can be recorded as separate lines rather than a dense string of technical fields. A small clear context block helps both people coordinate. It also reduces the chance that a site repair for one page is mistakenly treated as recovery for every finding that happened to share a similar label.

Separate URL form, destination selection, and live page behavior

A URL can be structurally valid and still point to an unavailable page. It can use HTTPS and still redirect to the wrong offer. It can open in a browser and still fail to complete the intended transaction. These are different checks. The assistant should normalize a supplied bare domain appropriately when preparing supported web destinations, but it must not describe that normalization as proof of reachability or policy suitability. A correct-looking string is the beginning of the investigation, not its conclusion.

Understand which destination the user wants to change. The ad's final URL, a sitelink destination, and a tracking template are different settings. Replacing a tracking template does not necessarily repair an incorrect final URL. Changing one ad does not change every asset that points to the same page. The requested operation needs its own target and supported fields. A generic instruction to “fix the link” should prompt enough context to determine which setting actually contains the problem.

Preserve meaningful URL components during review. A product path can identify the intended offer; a query parameter can affect selected content or measurement. Removing all parameters as a cosmetic cleanup can change behavior. A site's redirects may legitimately handle old paths, but the owner needs to confirm that the journey reaches the intended content. The assistant can help organize these questions without silently treating every unusual URL as incorrect. The actual business use determines which parts matter.

Do not equate measurement settings with destination availability. Auto-tagging and tracking templates can affect how traffic is identified or routed, yet a measurement issue may exist on a page that otherwise opens normally. A destination issue may occur with perfectly valid measurement configuration. When both are suspected, keep them as separate review tasks and use the applicable evidence for each. The article on tracking-template edits explains why removing a template needs its own scope and approval.

Investigate the intended journey rather than a single status code

A customer journey begins with the promise in the ad and continues through the destination. The page needs to match the intended offer closely enough that the visitor can take the relevant next step. For a booking campaign, that may include a functioning enquiry or appointment flow. For a retailer, it may include the right product variant and available purchase path. A site owner should test the intended journey with the offer context, rather than merely confirming that the homepage returns a successful response.

Separate direct observations from assumptions. A test can establish that a particular route opened at a particular time in a particular environment. It cannot establish that every location, browser, device, and customer sees the same result. An intermittent issue may need repeated or targeted investigation. The account conversation should record the relevant test conditions when they matter. This makes the evidence useful to an engineer without overclaiming universal success from one visit.

Known site changes can guide investigation. A migration may have changed product paths; a regional storefront may have changed redirects; a new access rule may affect external visits. The assistant can ask about those changes when the timing suggests a relationship, but it should not announce them as the cause without evidence. The site owner can verify the route and configuration. A targeted question such as “Did this collection path change in the release?” is more useful than a speculative account-wide explanation.

Some destination problems concern content or access rather than a technical outage. A page may be available but no longer present the advertised service. A page may require a sign-in the intended audience cannot use. A destination may show different content in a targeted locale. The correction depends on the actual problem. Keep the provider topic, observed page behavior, and business promise alongside one another so the reviewer can see whether they point to the same issue or require separate work.

Give the site owner evidence that can be acted on

A useful site handoff states the intended page, the associated offer, the observed issue, and the check context. Include the time of a direct test when one exists. Identify the advertising dependency so the engineer understands why the route matters. Avoid sending a generic campaign table and expecting the site team to guess which page failed. The task should be narrow enough to reproduce, while preserving the business context needed to decide the right destination.

The provider finding should be labeled as provider evidence. A destination-related topic can help the site owner inspect the relevant area, but it is not a live error log from the advertiser's server. If the only evidence is the provider finding, say so. If a direct page test also exists, record it separately. This prevents the engineer from searching for a specific response code that was never actually observed and prevents an advertising reviewer from treating a local test as the provider's formal recovery decision.

Ask the site owner for a concrete completion statement. “The route now resolves to the intended collection and the purchase journey was checked” is more useful than “done.” The exact details depend on the site and issue. The account operator can then check whether any advertising setting still needs to change and whether the relevant provider evidence has updated. This handoff closes the technical task without prematurely closing the advertising issue.

Keep a temporary response distinct from the permanent repair. An owner might decide to pause a campaign while an important destination is unavailable. That is an exposure-management decision, with its own target and confirmation. Restoring the site does not automatically authorize the assistant to enable the campaign. The owner should review the planned resumption, especially if the offer or schedule changed during the incident. Clear separation avoids a repair workflow unexpectedly starting spending.

Prioritize affected offers without inventing a loss estimate

Prioritization should consider intended use, business importance, and the confidence of the evidence. A landing page used by the main active offer deserves prompt investigation. An old paused campaign may be lower priority unless a launch is approaching. An account-level asset with unresolved attachment context needs that context before its active exposure can be described. A list sorted only by the number of findings may overlook a single destination that matters more than many archived variants.

Historical cost and outcomes can help the owner assess importance when requested. Use an explicit period and preserve the metric definitions. The cost recorded in a campaign before an issue appeared is not automatically wasted cost caused by that issue. A policy-rejected ad may not be serving at all. Other ads may continue reaching working destinations. Avoid multiplying the account's usual daily revenue by the age of a finding and presenting the result as verified lost sales.

Business deadlines provide useful additional context. A sale starts tomorrow, a service appointment calendar opens next week, or a seasonal campaign is due to resume. The owner can supply these facts conversationally. They help order the work without requiring a speculative financial calculation. The assistant can show which tasks are blocking the intended launch and which checks remain unresolved. That is a concrete decision aid even when the exact commercial impact cannot be measured from the available provider data.

Use a small priority queue rather than repeatedly publishing every known finding. Each item should have an owner, next step, and state such as needs site check, needs destination proposal, or awaiting provider follow-up. These are team work states, not official provider labels. A finding can remain present while its repair is underway. The queue should help the team coordinate the next action and distinguish new evidence from the same issue being reread.

Choose the repair that matches the actual problem

A site fault generally belongs to the site owner. A wrong final URL may require a supported advertising edit. An inaccurate sitelink label may require an asset-content change. A tracking configuration issue may require its own scoped operation. The assistant should determine which layer contains the problem before preparing a request. A destination finding does not authorize a universal rewrite of all URLs in the account, and a successful API call cannot repair a server route the advertiser controls elsewhere.

If the owner supplies a replacement landing page, resolve the advertising target and show the proposed destination clearly. The user should recognize the offer and the correct campaign or group context. A bare domain supplied in conversation can be normalized to a web URL, but an applicable tool still needs to validate its accepted form and target. Review the destination selection before confirmation. Do not silently select a homepage when the requested product or service page is missing.

Consider the scope of a reused asset. Changing one shared asset may affect more than the immediate campaign under discussion. An attachment change may affect only the relationship selected. The operation's actual semantics determine which proposal is appropriate. Use the supported field and dependency framework to resolve that distinction, and explain the consequence in the user's terms. When the framework cannot establish the required relationship, ask for clarification or use the appropriate account handoff rather than pretending the target is unique.

A temporary pause can be prepared as a separate supported response when the owner requests it. The proposal should name the actual entity and status transition. If the request includes repair plus later enablement, the sequence must preserve the dependencies and show each requested action. A discussion about a site fix alone should not become a campaign-status mutation. See campaign pauses from Slack for the distinction between performance evidence, target selection, and approved execution.

Three illustrative destination incidents

A retailer changes its collection paths

Imagine a retailer reorganizing its catalogue before a promotion. Some ads and sitelinks still refer to an older collection path. The Links command returns destination-related findings on the available provider surfaces. The account operator identifies the intended offer and asks the site owner whether the old path should redirect or whether the advertising destination should change. The report does not claim it just crawled the page, and the finding count is not described as a unique-page count.

The site owner confirms the intended new collection and checks the actual customer journey. The operator then requests supported account changes for the relevant targets. The proposal shows the destinations and readable context; the owner confirms before execution. A later provider read checks whether the relevant findings remain. The team keeps the successful site repair, verified advertising changes, and provider follow-up as separate milestones, making the incident understandable when another person reviews it afterward.

A booking route fails immediately after a release

Imagine a service business whose booking route stops working minutes after a website deployment. The provider-findings review is initially clean because the new fault has not yet been reflected in that evidence. A direct site test identifies the failed journey. The operator does not use the clean Links response to dismiss the report from the site team. The observations answer different questions: one concerns published provider findings, while the other concerns the page behavior at the time of the test.

The site owner repairs the route and checks the booking flow. The business owner decides whether temporary campaign containment is needed during the repair and approves any requested supported pause separately. Afterward, the operator reviews the intended serving configuration and applicable current provider state. A clean provider read can contribute to the review, but the launch decision also uses the direct site evidence. This avoids forcing every destination incident through a tool whose evidence has a different timing boundary.

A seasonal sitelink has unresolved attachment context

Imagine an agency finding an account-level sitelink with a destination-related topic for an old seasonal offer. The current deterministic result lists the asset in its enabled-side findings, but that classification does not resolve every attachment's serving status. The operator asks where the asset is used before describing current exposure or changing it. The asset may be relevant to a future launch, even if the known seasonal campaign is paused. Its name alone does not settle the relationship.

The team identifies the intended use and decides whether to repair the destination, update the asset, or adjust a supported attachment. The proposal states the actual consequence rather than presenting a generic “fix link” action. If the asset remains intentionally unused, the work record preserves that decision and a prelaunch check. This example shows why account-level asset findings need careful context: a useful broad detection surface does not automatically provide every relationship needed for a precise edit.

Use the Links command as an account finding review

Run /ppctor links in a channel connected to the relevant Google Ads account. The command reads the account's available destination-policy findings and posts an issue-focused result. It separates its enabled-side and paused-side lists, shows readable entity references and provider reasons, and counts overflow rather than dumping every row into the message. The current presentation lists up to ten examples in each category. A complete interpretation still needs the source and status limitations explained above.

If one provider surface cannot be read, the response warns that its unknown findings are absent from the counts. That warning belongs before interpreting a clean or small result. The tool can still provide useful evidence from the successful reads, but the account operator should not expand it into an all-surfaces clearance. If the account connection is unavailable, restore the authorized connection before treating any output as an account destination check. A connection failure is not evidence that the advertiser has no issues.

The result should guide the next focused review. An ad finding can lead to a question about its final URL and parent configuration. An account asset finding can lead to attachment-context inspection. An asset-group finding can lead to review of the associated offer and destination. The follow-up should ask for the missing piece that changes the decision. It does not need an unrelated full performance audit merely to explain a destination topic.

For a wider account review, /ppctor audit provides a different set of checks and their own population boundaries. Use the tool that matches the question rather than assuming all health commands report the same evidence. A general audit finding about disapproved enabled ads and a destination-topic review across several surfaces can legitimately have different counts. Explain the populations before comparing them. The article on policy monitoring describes how those policy checks differ.

Ask focused follow-ups that use available data deliberately

A conversational request can start with the destination issue already found: “Which final URL does this ad use?” The assistant should retain the resolved target context and select the supported field needed to answer. If the user asks for a table, it should render the returned evidence in a readable form. Data retrieval and presentation are separate steps, so changing the display should not trigger an unnecessary unrelated query when the required data is already available.

Another useful follow-up is “Is that campaign currently enabled?” That asks for configuration rather than proof of active impressions. A request for recent cost is a performance question and needs a dated reporting interval. A request to check a page live is a site-behavior question and needs a capable applicable tool or a site-owner handoff. The assistant should not use one available policy read to pretend it answered all three. Each answer must retain the evidence type on which it depends.

The user can also request help without live retrieval. “Write a short message to the web team explaining this finding” uses the established context. “Suggest a clearer sitelink label for this offer” can be creative discussion. These requests do not inherently require another Google Ads call. The assistant should use the conversation's confirmed facts and avoid adding unsupported claims. When the user later requests a live change, it resolves the target and prepares the applicable proposal.

Before confirmation, show the exact change and the correct parent context. A destination update needs the proposed URL; a status change needs the transition; a content replacement needs the relevant full intended content. The proposal should make the logical steps visible in ordinary language. After the owner confirms, the visible progress state indicates that execution is underway. The final receipt states the actual execution and verification outcome rather than implying that the website and provider review are both resolved automatically.

Verify the technical repair, account edit, and provider state separately

The first milestone is the technical or content repair on the website, when that is needed. The site owner checks the intended page and journey under the relevant conditions. That evidence belongs to the site task. It can establish that the route or offer now behaves as intended in the tested context. It does not prove that every advertising reference uses the corrected destination or that every relevant provider finding has changed.

The second milestone is the supported account change. If an ad or asset setting was edited, execution verifies the applicable resulting state where supported. A successful result can confirm that the new destination or content is present. It should not claim that the page was thoroughly tested unless a separate test supplied that evidence. If the result cannot be fully verified, inspect the account before sending another mutation. An ambiguous observation is not permission to duplicate a creation or repeat an update blindly.

The third milestone is the relevant provider-state follow-up. Read the current finding or policy information for the affected context and compare it with the original issue. A broad count falling does not establish that the intended specific item recovered if other findings changed at the same time. Keep target identity and scope consistent. If the team retires the target instead of repairing it, record retirement as the chosen outcome rather than calling the old destination fixed.

Finally, check the intended business configuration before declaring the launch ready. A working page and a resolved finding do not automatically enable a paused campaign. An owner may want to wait for the planned start time. If enablement is requested, prepare the explicit supported action and its confirmation. This keeps the repair process from unexpectedly starting spending and gives the final readiness statement a clear foundation: the intended journey, account state, and relevant evidence have been checked.

Make destination checks part of release and launch routines

Use provider-findings review as one component of a broader routine. Before a launch, inspect the intended advertising references and check known destination issues. After a site release, test the affected routes and customer journeys directly through the responsible site process. Before reusing paused seasonal advertising, review its destinations and current relevant findings. These tasks complement one another because they cover different evidence and timing. A single clean command result should not be treated as a universal release gate.

Maintain ownership of important advertising routes. The account operator should know whom to contact when a collection, booking form, or promotional page changes. The site team should know which routes have active advertising dependencies. This can be a small shared record rather than a complex system. Its value is preventing a routine site cleanup from unexpectedly removing a destination still used by the account. The assistant can help turn a confirmed incident into a clear handoff and a future check.

Review unresolved findings on a meaningful cadence. A known old issue on unused creative may need a future prelaunch task, while an intended active offer may need prompt investigation. The current Links tool is an on-demand review, not a promise of continuous page uptime monitoring. If the business needs real-time site availability checks, define that requirement separately with its own evidence and owner. Do not imply that a numerical account alert or a provider policy read automatically supplies that service.

Close the loop with a small documented lesson. A migration may need a route-retention checklist, an asset review may need attachment context, or a launch may need a final destination confirmation. Keep the lesson tied to the demonstrated issue. Avoid adding a broad recurring account crawl when the actual problem can be prevented by a precise ownership check. The aim is a faster, clearer response to real destination problems with fewer unnecessary reads and fewer unsupported claims.

Common questions about broken-link checks in Slack

Does the command open every landing page?

No. It reads Google's available destination-related policy findings. A live page investigation is a separate task.

Does a clean result prove a page changed today is working?

No. A recent failure may not yet appear in provider evidence. Use the site owner's direct checks for the current journey.

Does the finding count equal unique broken URLs?

No. It counts returned findings across the supported surfaces. Several entities can refer to the same destination.

Are account assets confirmed live when they appear in the enabled-side list?

No. That read does not resolve every attachment's serving configuration. Inspect the relevant relationships before describing current exposure or editing scope.

Can the assistant repair the website through an Ads edit?

No. Website behavior needs the site owner's repair. A supported Ads edit can change the applicable advertising setting after confirmation.

What does a complete recovery check include?

The intended journey, any changed advertising setting, and the relevant current provider evidence. Keep those milestones separate and preserve the actual target context.