Slack Google Ads broken-links command guide: understand the result and choose the next check

Choose the command for a provider destination review

The Links command answers a specific account question: which destination-related policy findings has Google published on the surfaces this tool reads? It is useful for an operator reviewing known advertising destination issues. It is not a live browser visit to every landing page. That difference should guide both when the user runs the command and how they interpret its result. A tool can be fast and useful without establishing every possible fact about a website.

Choose a direct site check for a current page-behavior question through the responsible site process or another applicable capable tool. Choose a performance report for measured cost or outcomes during dates. Choose the Policy command for its broader current status surfaces. The Links command can contribute evidence to those investigations, but it should not silently substitute for them. The user's purpose determines which observation is needed, rather than whichever command happens to be easiest to invoke.

A destination finding does not necessarily mean a missing page. Google describes several destination requirements, including functionality, consistency, crawlability, and access. Read the returned topic before deciding what to investigate. See Google's destination requirements. The command's common “broken links” description should not flatten every relevant policy topic into one assumed HTTP error.

Use the result to identify a concrete next task. The account operator may need the actual final URL of an ad. The site owner may need to inspect a route. A reused asset may need its attachment context resolved. A campaign may need a separately requested temporary response. These tasks have different targets and evidence. The command is a starting review, and its value increases when the user keeps the next question focused rather than immediately applying a generic account-wide change.

Use the actual command without undocumented flags

The current syntax is /ppctor links. Run it in the Slack channel connected to the intended Google Ads account. The handler selects that account through the connection context. It does not define arbitrary URL, campaign, or date arguments appended to the command. A user asking about one selected target can use a conversational follow-up after the broad account review. A user asking for a live test of one page needs the applicable site-check path instead.

The initial response acknowledges the request, and the account result is posted after the provider work. The command does not wait indefinitely inside the initial Slack request for all reads and delivery. That staged behavior helps the user recognize that work has started. It should not be mistaken for an empty final result. Wait for the result or an explicit failure state before deciding whether the review completed.

Do not rerun the command repeatedly to make a pending result faster. Another invocation can create more provider work without changing the first request's state. If the expected result is missing, inspect the actual authorized run or delivery evidence. A slow visible response can involve provider work, connection resolution, or message posting. These are different stages, and repeating a broad read is not a reliable repair for a delivery problem.

Keep a short instruction for colleagues: choose the correct connected account channel, type the exact command, and read the source caveat and any unread warning before interpreting the count. That is more useful than a list of guessed command variants. Product documentation should match the current handler. The broader benefit of destination review can be explained in ordinary language while the usable command remains precise.

Check the authorized account and message context

The command needs an authorized Google connection and a reachable selected account. The headless path obtains the applicable access token and account context before reading destination findings. If authorization is unavailable, the owner needs to restore it. If the account is no longer reachable through that login, account access needs investigation. Neither failure establishes that the account has zero destination issues. The tool has not yet obtained the evidence required for that conclusion.

The channel binding identifies the intended account. An agency should still check that it chose the correct client channel and audience before posting account evidence. Similar visible names are not enough to establish identity. The authorized tools retain exact identifiers internally while the normal message should use a recognizable account name. This keeps the conversation readable and avoids exposing account details that do not help the client understand the finding.

Slack posting is a separate prerequisite from the provider read. A valid account connection does not guarantee that the result can be delivered successfully. The current command posts through the response path and logs unsuccessful delivery. If a user reports no visible result, the operator should distinguish failed retrieval from failed posting. The account may have been read even when the channel did not receive the final text.

There is no live edit in running this command. The user can request the review without approving a destination change or campaign pause. Later account changes need the applicable supported target and confirmation workflow. This boundary should be clear to a teammate who wants to inspect account health but does not have commercial authority to decide how the offer should change. Detection and authorization are separate jobs.

Understand the ads, assets, and asset-group surfaces

The current collection reads three independent Google Ads surfaces. The ad surface obtains destination-related policy topics with campaign and ad-group context. The account asset surface obtains policy topics from assets such as sitelinks regardless of which attachment level initially holds the asset. The asset-group association surface supplies relevant context for group-based creative structures. These reads run together and retain their successes even when another surface cannot be read.

The ad query excludes removed ads and removed campaign and group parents. It retains non-removed paused contexts as well as enabled ones. The asset-group query excludes removed campaign and group parents. The account asset query does not resolve every attachment's serving configuration. This coverage makes the review broader than a single active-ad report, while also giving the result specific status and relationship limits. The user should inspect those limits before describing current business exposure.

The collection selects topics whose identifiers concern destinations, landing pages, or URLs. It is not every policy issue in the account. A non-destination content finding may belong in the Policy review instead. A product issue may belong in Merchant evidence. The choice of topic determines what the Links command reports, so a clean result cannot establish that every other policy surface is healthy. Use the command's actual evidence selection when stating what has been checked.

A surface can produce more than one entity pointing to the same page. An ad and a sitelink can reference a related destination; a reused asset can occur in group context. The collection returns finding rows, not a deduplicated URL inventory. If the user needs the number of distinct pages, request an applicable URL-level analysis and define the deduplication rule. Do not treat the combined finding count as a unique-page total merely because the tool's name mentions links.

Interpret Live and Paused as the tool's grouping labels

The current message uses Live and Paused headings to separate its returned findings. For ads, the enabled-side condition checks that the ad, ad group, and campaign are enabled. For asset-group findings, it checks the group and campaign configuration. These conditions describe configured status. They do not establish measured impressions, current spending, or successful delivery. A destination-related policy issue can itself affect whether a configured target serves as intended.

The account asset surface has no equivalent standalone enabled-or-paused state that resolves every attachment. The current implementation places these asset findings in the enabled-side list. The user should therefore interpret an account asset row as needing attachment-context review, not proof that it is active in every campaign or spending now. A sitelink can be reused, and its business relevance depends on the actual relationships the owner intends to use.

The current label “serving right now” is broader than the underlying configuration evidence proves. When discussing the result, describe the selected enabled context and any unresolved asset relationships accurately. Do not calculate wasted current cost from that phrase. Actual activity requires dated performance data. This is an important reading rule because an ordinary-looking status sentence can otherwise carry an unsupported financial implication.

The paused-side list remains valuable for future use. A team may have paused an offer when its destination failed and never repaired it. A seasonal campaign may be due for reuse. These findings can inform a prelaunch check even when they have no established present spending exposure. Keep them distinct from intended enabled use and ask the owner about the future plan before assigning urgency or preparing a status change.

Read finding totals separately from listed examples

The current renderer lists up to ten examples in each displayed category and counts additional findings. The visible bullet list is therefore a preview when overflow exists. The total comes from the returned finding population, not from the number of rows a person can see in the message. If a user asks how many findings exist, use that population. If they ask which targets they should inspect first, use a clearly labeled readable subset.

A finding count is not necessarily a count of unique assets, campaigns, or destinations. Several findings can share a campaign. A reused asset can have different context. A page can be referenced by several entities. The assistant should state the counting unit when answering a follow-up. A precise count with the wrong unit can be as misleading as a rough estimate, because the user may apply it to a different business question.

Unread surfaces are not part of the returned total. If the asset-group read fails, the known ad and asset rows remain useful but their count cannot include unknown group findings. A small result should not hide that limitation. The warning belongs before the conclusion. The owner can act on known evidence while keeping the missing read as a separate unresolved task.

Do not derive account savings or losses from the count. Ten findings do not mean ten pages currently wasting money. Some can be paused, some can concern an unresolved attachment, and some can involve policy meanings other than a missing route. A business-impact request needs additional evidence and definitions. The tool can identify where to inspect; it does not provide a counterfactual revenue estimate by counting returned rows.

Read a representative posted result carefully

The following invented example illustrates the output structure without using private customer information. Imagine a fictional account named “Summit Repairs” with one finding in a paused ad context. The response identifies the account, separates its categories, names the relevant creative and parents, and includes the provider-evidence caveat. The example is a presentation illustration, not a reported customer incident or an assurance about any real account.

The useful reading order is account, warning if present, category, entity, parent context, and reason. The account confirms the selected connection. A warning changes the coverage of the count. The entity and parents locate the advertising reference. The reason directs the next investigation. The caveat establishes the source and timing limit. Skipping those parts and reading only the number can produce a broader conclusion than the evidence supports.

The current output is text-oriented rather than a complete interactive repair form. It does not necessarily include every final URL needed for a site handoff. If the user asks for that detail, the assistant can use a supported field read for the selected target. If the visible creative label is ambiguous, the parent context helps resolve it. The follow-up should fill the specific missing piece rather than pretend the initial message contained a full route inventory.

Keep examples honest in documentation and client explanation. An invented example can teach the structure, but it should not be described as a real measured result. A real account finding needs the actual provider evidence and authorized context. The same rule applies to claimed recovery: a sample success message cannot establish that the user's destination was repaired. The user deserves a clear distinction between an illustration, a current finding, and a verified action receipt.

Use clean and partial results within their actual scope

A clean result means no matching destination-topic findings were returned in the successfully read surfaces. It does not mean every landing page has just been opened. It does not certify all policy requirements or product-feed states. The source caveat is part of the result's meaning. A team can use the clean provider review as one input while still performing a direct site acceptance check for a recent release or planned launch.

A partial result names the surfaces that could not be read. Those areas remain unknown and are not represented in the count. The command isolates these failures so useful successful evidence remains available. That is better than discarding the whole review, but it requires an honest conclusion. “No findings among the surfaces we read” is not the same statement as “No findings anywhere in the account.”

A missing account connection is not a partial destination result. It is an unmet prerequisite before the relevant reads. A failed Slack post is a delivery state after retrieval may have happened. The operator should identify the actual stage before choosing a retry or correction. This prevents ordinary troubleshooting from becoming repeated account scanning with no progress on the underlying authorization or message issue.

Use an explicit closure condition when the user needs readiness. If the launch depends on a selected asset-group destination and that surface is unread, the readiness conclusion remains incomplete. If the known finding concerns an obsolete paused offer the owner retires, retirement can be a valid outcome. A clean result or a partial result is evidence for a specific question, not a universal instruction to enable every target or declare every issue solved.

Understand the time boundary between a provider read and a site test

The command obtains current published provider evidence, but the evidence itself reflects Google's observation and review process. A page that broke minutes ago may not yet appear. A repaired page can need a later relevant provider-state check. The headless path does not reuse a stale destination summary as though it were a new live page test. Even a fresh provider request remains a different observation from opening the page at that moment.

For a website release, use the site's own acceptance process to check the affected customer journeys. The operator can then inspect provider destination findings when relevant. A direct test can identify immediate route behavior; the command can identify published advertising findings. If their observations differ, state the timing and evidence type rather than force one to invalidate the other. They may be describing different moments or different aspects of the destination.

Keep timestamps useful without exposing unnecessary internals. A site engineer may need the time and conditions of an observed failure. A client may need only the dated incident and its current work state. A provider retrieval timestamp alone does not prove when the page failed or when a finding first existed. The assistant should not invent a timeline from the latest read. Use actual recorded events when the incident requires a chronology.

Do not promise a universal update interval for all destination findings. The appropriate follow-up depends on the issue and provider process. The command can be run when a relevant check is justified, but repeated requests do not force the provider to publish a different state. The owner should know which upstream correction occurred and which current evidence is being inspected next. That makes waiting meaningful rather than an endless series of unchanged reads.

Understand the provider reads and output request

The destination collector starts three independent provider queries, one per defined surface. It obtains the status context alongside the topics, then divides the successful rows into its display categories. The enabled and paused lists do not require a second identical query batch. This is the base collection behavior. Authorization, account resolution, actual retry behavior, and delivery can involve additional external work, so the complete command should not be advertised as an invariant three-call total in every circumstance.

Google counts Search and SearchStream requests as operations under its applicable quota rules. Parallel execution reduces elapsed waiting but does not remove the usage cost of each request. A streamed response can return batches without counting every batch as a new SearchStream operation. See Google's API quota guidance. The app's actual request selection and the provider's counting rule are separate parts of the usage explanation.

The current command does not send a request to each advertiser page. That avoids turning a broad Slack review into a large website crawl. It also means there are no measured page response times or live route results to report from this command. The trade-off is explicit: efficient published-provider evidence with a known observation boundary. If the business needs continuous site availability monitoring, define that as a separate requirement with an appropriate tool and owner.

Slack result posting has its own request and failure state. A failed post can be logged even after successful collection. The user should not treat a missing message as a zero provider result. The operator can inspect the actual stage through authorized diagnostics and resolve delivery without automatically repeating the whole account read. Efficient use comes from selecting the needed evidence and respecting completed work, not from suppressing legitimate checks.

Request the target detail needed for the next decision

Ask for the selected ad's final URL when the site handoff needs it. Ask where an account asset is attached when its current relevance is unclear. Ask whether the parent campaign is enabled when configuration matters. Each is a focused question with a specific evidence type. The generic reporting and relationship framework can discover compatible fields and datasets, then read the required context. It does not need a new dedicated function for each phrasing of the same target question.

The assistant should retain the target and account context from the preceding result when they are clear. A follow-up saying “that booking ad” can refer to the resolved finding. If several targets fit, ask for selection using the known parents. Do not silently choose the first row or expose a raw identifier as though it solved the ambiguity. Readable exact context supports both a useful answer and a later reviewed action.

A request for measured exposure needs dates and metrics. Current configuration alone cannot answer how much the target spent during a recent interval. A historical report can include cost from a target that is paused now. The answer should retain that distinction. A provider-rejected destination does not automatically make every historical unit of campaign cost wasted. The user can ask for the relevant activity, but the causal interpretation needs more than a topic label.

A request to change the display can reuse evidence where it already supplies the necessary rows. A new field or segmentation can justify a new read. A creative message to the site owner can use the established context without another API call. The assistant should make tool use follow the question rather than default to a whole-account collection for every reply. This keeps the thread responsive and the resulting explanation consistent with the actual evidence.

Create a site handoff that can be reproduced

The site owner needs the intended destination, the associated offer, and the actual observed evidence. Label a provider finding as provider evidence. Label a direct test as a direct test with its relevant time and conditions. A generic “Google says links are broken” note is too vague to reproduce. A clear handoff lets the engineer inspect the correct route without guessing which campaign, locale, or customer journey the account operator meant.

Ask the business owner to confirm the intended replacement if the old page no longer exists. A homepage may be reachable but unsuitable for a particular service or product offer. The assistant should not pick it as a silent fallback. The correct destination needs to preserve the advertising intention. Once that page is established, the site owner can check its behavior and the account operator can prepare any applicable advertising-reference change.

Do not reduce the site task to a successful status code when the intended journey needs more. A booking page may open while its form fails. A product page may load while the intended variant is unavailable. A redirect may reach a working page with the wrong offer. These are direct investigation questions for the site process, not facts supplied by the Links command. Preserve them as specific checks rather than claiming the command performed them.

Request a concrete completion statement from the site owner. It should identify what changed and what journey was checked. The account operator then knows whether the advertising destination itself still needs an edit and which provider-state follow-up remains. This avoids a premature all-clear after one layer was repaired. The incident can progress through clear milestones without turning every handoff into a long technical report for the client.

Prepare account changes with the correct target and consequence

A destination finding can lead to a supported account proposal when the owner requests a specific change. The framework should resolve the actual ad, asset, or relationship and check its prerequisites. A final URL change is different from a tracking-template change, and a shared asset update can differ from changing one attachment. The proposal should explain the actual operation in the user's terms. A generic “fix link” instruction does not establish which layer should change.

A supplied bare web domain can be normalized for an applicable landing-page field, but that formatting step does not establish reachability. The proposed URL should remain visible for review. If the target requires full creative content, the proposal must include that content and its relevant consequences. The owner should be approving the actual resulting configuration, not a short technical label hiding a broader replacement.

Confirmation is required before a conversational live edit. The message names the target and correct parents, lists the exact steps, and states that no changes have yet been made. After the owner confirms, a visible progress state shows execution has started. The final receipt reports the actual execution and verification outcome. This preserves a clear boundary between reading a destination finding and changing the account because of it.

Temporary status changes need the same clarity. The owner may want to pause an intended campaign during a site repair. That is a separate risk decision, not an automatic response to every finding. Later enablement is another requested action with its own prerequisites. A site completion message should not silently trigger spending. See the confirmation and execution workflow for the reviewed action boundary.

Three illustrative command sessions

A collection migration produces several references to one page

Imagine a merchant moving a collection to a new path. Several ads and sitelinks still reference the old destination. The command returns findings across its successful surfaces. The operator does not claim the finding count equals distinct broken pages. A focused follow-up resolves the intended URL and the relevant references. The site owner confirms whether a redirect or an advertising-reference change is appropriate for the actual customer journey.

The owner requests supported changes for the selected account targets and reviews the concrete destinations before confirmation. The site repair and the Ads edits have separate completion evidence. A later provider read checks the relevant findings. The thread records the same intended offer throughout, avoiding a situation where one repaired route is mistakenly treated as recovery for every returned entity.

A clean provider result follows a brand-new site failure

Imagine a booking route failing immediately after a website release. The Links result contains no destination-topic findings yet. The site team has a direct failed-journey observation. The operator treats these as different evidence sources, not a contradiction proving the site team wrong. The command describes published provider findings; the site test describes current behavior in its tested context. The technical repair proceeds through the site owner.

The business owner separately decides whether a temporary campaign response is needed. Any requested pause has a reviewed target and confirmation. After the route repair, the intended journey and account configuration are checked, with relevant provider evidence inspected when appropriate. The command remains useful within its scope while the urgent current fault is handled by the process that actually observed it.

An asset finding needs attachment context

Imagine an account asset labeled “Winter Offers” appearing in the enabled-side list. The current asset read does not establish every attachment's configuration. The operator asks where that asset is used before claiming current exposure or preparing a shared-content change. The business may have archived the offer or planned to reuse it next month. The visible label alone cannot decide either its urgency or the scope of a supported operation.

The team resolves the relevant relationships and chooses a repair, attachment change, or documented retirement through the applicable path. The proposal shows the actual consequence if a live edit is requested. A later launch check can remain scheduled as a team task without implying that the Links command continuously monitors the page. This is a precise response to the finding rather than an account-wide cleanup based on an unresolved association.

Complete the follow-up with separate evidence milestones

First establish the site outcome when a repair is needed. The site owner checks the intended route and journey. That evidence does not prove every advertising reference uses the repaired destination. Second establish any supported account edit through its execution and verification result. That evidence does not prove Google's relevant destination state has changed. Third inspect the current provider evidence for the selected context. Each milestone answers a different unresolved question.

Use the same target and scope for closure. A total finding count decreasing does not identify which item changed. A page being reachable does not identify whether the original creative now points to it. A paused target being corrected does not establish that the owner wants it enabled. The closure statement should name the selected outcome and the evidence that supports it. It can remain concise while still being exact.

If verification is uncertain, inspect the account before requesting another mutation. An edit can succeed even when its later observation fails. Repeating a creation can add another entity rather than recover the first result. The assistant should report the actual state of knowledge and guide the next applicable check. This is a distinct troubleshooting task from a provider finding remaining unchanged after a site repair.

Keep a compact handover for unresolved work. Record the intended offer, selected advertising context, observed topic, completed correction, and next owner or event. Do not leave the thread with only “try again later.” A site release, an owner-selected destination, or a current provider-state check can be the next meaningful step. The broader article on destination review and repair ownership explains how these tasks fit the business workflow.

Use the result as one part of a prelaunch decision

A prelaunch review should identify the intended advertising references before deciding which evidence is sufficient. The account may contain many old findings that do not belong to the launch, while one selected destination remains important. Write down the campaign or group the business intends to use, the offer it will advertise, and the page the customer should reach. Then inspect the relevant known provider findings and arrange the appropriate direct site check. This gives the launch decision a defined population rather than a general reassuring account count.

Ask whether the selected destination still represents the current offer. A technically available page can contain last season's terms or an unavailable product variant. The offer owner should confirm the intended content, while the site owner confirms the journey behavior. Those checks are not supplied by a clean provider-topic result. Keeping their ownership explicit avoids a situation in which the account operator assumes the site team checked the promotion and the site team assumes the advertising team approved the terms.

Resolve unknown attachment context when it affects the launch. A reused account asset can appear in a broad finding list without the tool establishing which current campaign relationships matter. The operator should inspect the relevant association before updating shared content or deciding the launch is unaffected. The next question is narrow: where is this asset used in the intended setup? Answering it is more useful than running the same broad collection repeatedly while leaving the actual launch relationship unresolved.

Keep the readiness decision separate from enablement. The team may finish its checks today while the promotion is scheduled for Friday. A confirmed working destination and an acceptable provider-state review do not authorize immediate spending. If the owner asks to enable the selected account targets, prepare that supported action explicitly with its current prerequisites. This makes it possible to complete preparation without accidentally starting delivery before the business wants it.

A review can also conclude that the selected launch should change. The owner might choose another approved offer, postpone the start, or retire an obsolete asset. Record the decision and its reason rather than calling the old destination repaired. The tool contributes evidence to the decision; the business chooses the intended outcome. A concise record of the selected target, checked journey, relevant provider state, and planned configuration helps the next operator understand exactly what “ready” means in this launch.

After launch, a requested performance check can examine actual dated activity. It should use the agreed measure and scope, not infer success from the fact that preparation completed. A sound prelaunch process makes the intended journey reviewable, while the later report shows what happened. These are complementary observations. Keeping them distinct prevents the command's destination evidence from becoming an unsupported promise about future cost, conversions, or revenue.

Common questions about the Links command

What should I type?

Use /ppctor links in the intended connected account channel. The current handler does not define arbitrary URL or date flags.

Does it test every page live?

No. It reads destination-related findings published by Google on the three defined surfaces.

Does Live mean verified current spending?

No. The grouping uses configuration context, and account assets lack resolved attachment status in that read. Actual activity needs dated performance evidence.

Does the count equal unique broken pages?

No. It counts findings. Several advertising references can concern the same destination.

Does a clean result replace a release test?

No. A recent fault may not yet be present in provider findings. Test the intended site journey through the appropriate process.

Does running the command change the account?

No. Supported account changes need a concrete target, readable proposal, and confirmation before execution.