Google Ads broken-link checks for agencies: know what was checked and who acts next

Define the agency destination-checking job

An agency destination check should help the team connect a reported advertising problem to a concrete website or account task. Its purpose is not simply announcing that something is broken. The useful result identifies the client account, affected item, available evidence and next owner.

The agency's practical constraint is that advertising and website responsibilities often sit with different people. A specialist can read an ad's destination finding but cannot necessarily repair the client's hosting, product page or form. A good handoff bridges that gap without claiming access the agency does not have.

Define why the check is being requested. Launch preparation, a recent website change and an investigation into low delivery can need different priorities. A finding on an old paused offer is not automatically as urgent as one on the promotion the client intends to launch tomorrow.

Keep the evidence source visible. Google's published destination verdict is useful advertising evidence, while a live website test answers another question. The agency should not treat either as a complete substitute for the other.

The resulting process is a sequence of accountable steps: read the supported evidence, resolve the item, assign the relevant investigation, prepare any appropriate account change and check the later state. Each step should establish its own fact instead of hiding several assumptions inside a generic fixed message.

Understand the evidence source

ppctor's Links workflow reads destination-related policy topics published by Google. It does not fetch every advertiser landing page to perform a new live crawl. This keeps the chat workflow focused on provider evidence rather than sending a large set of requests to the client's website.

The trade-off is timing. A page that broke recently may not appear in the published verdict yet. A page repaired after Google's observation can still have a reported finding until the relevant provider evidence changes. Both situations require careful interpretation.

Read a successful clean result as no returned destination findings within the checked surfaces. It does not prove every website page is operational, every form submits correctly or every customer can complete a purchase. Those are separate tests.

Likewise, a returned finding is evidence of Google's reported condition. The agency should investigate the actual target rather than assume the current cause from a broad label. Website owners may need to inspect relevant behaviour under the conditions appropriate to the finding.

This distinction should survive client communication. State that the report concerns Google's destination evidence and identify the next check. A technically accurate short explanation is more useful than a sweeping promise that the entire website has been tested.

Separate destination problem types

Google's destination requirements distinguish functionality, destination mismatch, crawlability and accessibility concerns. These are related to the user journey but do not all mean the same technical failure.

A broad destination-related topic can therefore need different evidence. A website owner should inspect the actual reported requirement, intended URL and relevant page behaviour. The agency should not turn every finding into a claim that the page returned a particular HTTP error.

Keep observations separate from hypotheses. The specialist can suggest that a redirect, unavailable page or incorrect destination deserves investigation, but those suggestions are not verified causes until the responsible person checks them.

A correction should address the observed problem rather than simply make the message look cleaner. Rewriting ad copy does not establish that a destination is reachable. Changing a URL does not establish that the new page matches the offer or works throughout the intended journey.

Use the provider's terminology where it helps identify the requirement, then explain the next task plainly. The client needs to know what evidence to supply and who should act. It does not need an invented technical diagnosis that the report cannot support.

Read the supported coverage

The current destination reader checks three independent surfaces: ads, account-wide assets and asset-group assets. It collects destination-related topics from their available policy information. The account-wide asset read is important for items such as sitelinks that can be used beyond an individual ad group.

The ad path includes non-removed ads with non-removed groups and campaigns. The asset-group path also excludes removed parent contexts. Paused items can therefore remain in the review when they are relevant to future use.

Coverage is defined by those provider resources and published topics. The tool does not claim to enumerate every URL on the client website or run a full website health audit. A general site problem may require a separate investigation even if no advertising destination finding is returned.

Keep the asset type and parent path where available. An ad finding can identify campaign and ad group; an asset-group finding uses campaign and asset group. An account-wide asset row may not supply the same attachment context.

Understanding this coverage helps the agency choose the next useful question. The team can investigate a named returned item while acknowledging that another part of the website or advertising journey was not checked by this read.

Retain partial-read warnings

The destination collector runs the independent surfaces together and preserves successful results when another surface fails. It names the unread surfaces instead of silently reducing the count. A partial report can support useful investigation as long as the limitation remains visible.

No returned findings with an unread asset surface does not prove that all assets have clean destinations. The correct interpretation is limited to the successfully read population. Missing evidence is unknown, not a zero finding count for the inaccessible area.

Assign the read problem separately from a verified destination issue. The agency can work on an affected ad while another owner investigates account access or an unavailable resource. There is no need to discard trustworthy returned evidence simply because coverage is incomplete.

For launch-critical items in an unread surface, obtain the relevant authorised evidence before treating the check as complete. A reassuring account summary should not hide the fact that the intended sitelink or asset could not be assessed.

Carry this qualification into the next handoff. Another colleague should see what was read, what was not and which task remains open. Otherwise a temporary provider-read issue can become an unexplained clean result in the client's record.

Interpret enabled and paused context

For ad findings, the reader checks the ad, group and campaign statuses when deriving the enabled subset. An enabled ad inside a paused group or campaign does not have the same configured context as an ad enabled all the way up its parent path.

For asset-group findings, the relevant group and campaign statuses determine the corresponding subset. This is a configuration classification. It should not be described as proof that the item received impressions or cost during a chosen historical period.

A destination policy finding can itself restrict serving. Consequently, enabled configuration does not establish that the item is successfully delivering right now. Use a compatible performance read if the client asks about observed impressions, clicks or spending.

Paused findings can still matter. The client may plan to relaunch an offer, or a colleague may use an old asset later. Keeping them visible helps preparation without treating every old item as an urgent active incident.

State the intended use alongside the current configuration. This gives the agency a practical priority: an enabled launch-critical asset, a paused future offer or an unused historical item can require different responses while carrying similar destination evidence.

Handle shared assets carefully

The account-wide asset resource carries destination policy evidence, while enabled or paused status belongs to the attachment context. The current Links reader retains account-wide asset findings without independently resolving every attachment's serving state.

Those rows should not be used as proof that each affected asset is currently serving or costing money. The review can establish the returned destination finding while leaving its full usage context for a supported additional investigation.

A shared sitelink may be relevant to several campaigns. Before preparing an edit, identify whether the operation changes the asset itself or a particular attachment. The scope of the correction can be wider than the campaign where the problem was first noticed.

Do not assume a parent path exists where the provider row does not supply it. Ask for or retrieve the supported context needed for the intended change. A guessed parent is worse than a clear statement that the finding was read at account asset level.

This limitation is especially important for agency handoffs. The website owner can investigate the named destination finding, while the account specialist resolves the asset's relevant usage. Neither should infer a complete active attachment inventory from the original finding count.

Distinguish findings from unique pages

The returned rows are advertising item findings. They are not automatically unique URLs, unique website faults or independent customer journeys. Several items can point to the same destination, and one item can have more than one destination-related topic.

Keep the count's unit explicit. A statement about five findings should not become five broken pages unless the evidence actually establishes five distinct pages. The agency can group related investigation tasks without changing what the original count measures.

The Slack output presents a readable preview and indicates additional rows. The displayed examples do not define the total population. A count answer should use the complete successful scoped result with its unread qualification.

Do not add overlapping account and campaign views as separate incident totals. A later narrower report may contain some of the same items. Reconcile their populations before presenting an aggregate to the client.

For a website handoff, it can be useful to identify a common destination after resolving the actual URLs. Label that grouping as an investigation organisation rather than claiming the original tool already deduplicated the account into unique technical failures.

Prioritise the client's intended journey

The most useful priority combines available destination evidence with the client's intended use. A campaign launching a new offer can make a paused ad important. An old unused sitelink can be lower urgency without having a clean provider verdict.

Ask which offer and user journey the client wants to preserve. A retailer may need a specific product page; a service business may depend on a contact form. The account report cannot infer every commercial requirement from the asset name.

Use observed performance only when it is needed for the decision. Recent cost or clicks can provide context for the selected scope, but enabled status does not substitute for those metrics. A destination finding alone does not quantify lost sales.

Keep the next task bounded. Resolve the intended URL, identify the responsible website owner and request the relevant check. A vague instruction to inspect the entire site can delay a straightforward correction and obscure the launch-critical problem.

Record priority as the agency's operating decision. It is supported by the client's plan and available evidence, not a hidden automatic assessment of revenue risk. Another colleague should be able to understand why this item was reviewed first.

Confirm the intended final URL

The intended final URL is a business and implementation choice. It should match the offer and the page the client actually wants users to reach. A domain alone may be insufficient when the ad concerns a particular product or service.

When the user supplies a bare public domain for a supported creative request, the app can normalise it to HTTPS. That convenience does not prove that the resulting page exists, is accessible to the provider or is appropriate for the advertised offer.

Ask for missing landing-page information before preparing creation. Do not invent a product path from the title or copy a URL from another client. The assistant needs the actual intended destination, especially when campaign names and product labels repeat.

Keep display paths separate from the final URL. They can describe an ad's presentation without proving that a corresponding page path exists. A correction should not silently equate a display label with the website location to be changed.

Confirm the full desired creative where the supported replacement requires it. Changing a destination within an existing responsive search ad operation can involve complete replacement behaviour. The reviewer should see all relevant resulting content, not just the URL in isolation.

Assign a separate website journey check

A functioning landing page and a functioning customer journey are different checks. The page may open while a form, checkout or product-selection step fails. Google's published destination finding does not certify the full workflow.

The agency can ask the responsible website owner to test the intended journey and report what was observed. The requested test should match the business objective. For a lead page, that may concern the expected submission flow; for a retailer, it may concern the intended product route.

Keep supplied test evidence labelled. A developer's report about a successful manual check is useful context, but it is not a fresh provider verdict returned by ppctor. The later Google status still needs its own read if the incident depends on it.

Do not claim that the conversational tool automatically submits forms or completes purchases. Those actions can have business consequences and are not part of this destination-evidence workflow. The article's suggested website investigation remains a separate human responsibility.

Record the relevant conditions and date of the check. This makes it easier to investigate a later discrepancy without assuming the website was permanently healthy. A useful handoff states the actual observation rather than a broad all systems work assertion.

Identify who can change the page

Find the person with the appropriate website access and responsibility. An advertising specialist may not control the page template, hosting configuration or redirect rules. The client contact can help route the task without requiring the agency to guess who owns the technical system.

Supply the named advertising item, available destination finding and intended page. The recipient should understand what prompted the investigation and which business journey matters. A screenshot of an unexplained count is rarely enough to act.

Separate website work from account work. A developer can repair a page while an account specialist verifies the intended creative. Neither task automatically completes the other, and both may be needed before a launch review can close.

Keep authorisation practical. Access to a connected advertising account does not imply permission to make arbitrary website changes. Conversely, a website owner cannot necessarily approve the account mutation through the application's connected-owner controls.

Record the next handoff after the repair. The developer supplies what changed; the account team performs the relevant later provider check. This makes the incident move forward without repeatedly asking the same person to fix an advertising status they do not control.

Check destinations around a launch

Launch preparation should focus on the actual intended creative, assets and pages. A clean read of old campaign items does not establish that a newly supplied destination is ready. Identify the offer, intended URL and asset parents before selecting the evidence.

Ask the website owner to complete the relevant page and journey checks in time for the advertising review. The agency can then inspect available provider evidence without assuming that a draft URL represents a finished destination.

Keep paused launch items visible. They can be important even without historical cost. A current destination finding on a paused ad should not be dismissed solely because it is not intended to serve until later.

Separate creation from enablement. A standard conversational responsive search ad creation starts paused, and its account operation does not guarantee provider approval. The launch record should show the remaining state checks and intended enablement decision.

Allow for unresolved evidence. The agency can explain that a page was supplied or repaired while the provider state remains to be checked. This is more precise than telling the client that launch readiness is complete because one account mutation returned successfully.

Work through an invented destination incident

The following scenario is invented; no customer results or identifiers are used. A fictional agency, Harbour Lane Ads, prepares a service client's seasonal promotion. The intended ad is paused, and the destination reader returns a finding associated with its landing page.

The same report contains an account-wide sitelink finding and an unread asset-group surface. The agency does not treat the sitelink as proven active delivery, and it does not describe the unread surface as clean. It records these qualifications before assigning tasks.

The website owner supplies a corrected page and describes the observed journey check. The account specialist confirms the intended ad content. If the actual account URL needs a supported change, the assistant prepares a precise proposal rather than changing every asset with a similar name.

After execution, the agency checks the saved configuration and later reads Google's evidence. The incident record distinguishes website repair, account correction and provider state. It contains no claimed lost-revenue amount and no assertion that the whole website was automatically tested.

Run the Slack Links command

Use /ppctor links in the connected account channel to request the dedicated destination-evidence read. The command acknowledges the request and posts its result after the provider work. It is an on-demand check rather than a continuously running website crawler.

Start with the account context and any unread-surface warning. The output includes grouped examples and indicates additional findings beyond the bounded preview. Interpret the total as returned advertising findings, not a complete inventory of unique website faults.

Read the enabled and paused groups with the underlying evidence limits in mind. The ad and asset-group paths have parent-status information; the account-wide asset path does not independently resolve all attachment states. A label alone should not become a spending claim.

Ask for a focused next step in the conversation. Identify the affected item and what needs clarification: intended URL, actual parent, website ownership or later provider state. This helps the assistant choose the appropriate supported read or conversational explanation.

For general command context, see the Slack broken-links command guide. For broader provider conditions, use the agency policy-monitoring guide. The tools serve related but different review purposes.

Use conversational follow-ups efficiently

A follow-up should preserve the resolved account and target. Asking what the same finding means does not justify switching to another campaign or reading unrelated cost metrics. Use available context until the question genuinely requires additional supported evidence.

The generic reporting and settings tools can describe fields and build compatible plans. If the user asks about observed performance, select the relevant population, dates and measures. If the user asks for an explanation of supplied context, a creative or explanatory response may need no provider call.

Do not generate a missing URL or parent from an asset's title. Ask for the necessary fact or retrieve it through an appropriate supported field. A plausible-looking path is not proof of the actual account configuration.

Keep commercial facts separate from provider evidence. The client can say which page should receive visitors; the tool can read current settings where available. The assistant should not claim that the API verified the client's business intention.

When a field or surface is unavailable, state the actual limitation and next useful action. Missing detail should not become a confident technical diagnosis or a blanket claim that Google does not expose any relevant data.

Choose the right correction boundary

Decide whether the problem needs website work, an account edit or both. A page repair can occur without changing the ad's final URL. A wrong final URL can require a supported account operation even when the intended page itself works.

The app should not promise a universal automatic destination repair. The standard conversational HTTPS-fix action is unavailable because reachability verification is required. Normalising a supplied URL for a supported creative request is a narrower capability.

An audit recommendation and a conversational tool are also different paths. The existence of a setting check does not establish that every resulting finding has a live fix exposed to the assistant. Read the supported operation for the actual asset type.

For a shared asset, consider the usage scope before changing content. A correction to the underlying asset can affect more than the campaign where the issue was noticed. Resolve the intended target and make the scope understandable in the proposal.

Do not combine website repair and account execution into one unexplained done state. The agency should be able to say which part it completed and which part still depends on the client or provider. Clear boundaries make uncertainty manageable.

Review an account edit proposal

If an account change is requested and supported, prepare the exact target and operation. Show the relevant asset and parent names. A human reviewer should not need to infer the destination change from technical resource syntax or an unexplained identifier.

For a responsive search ad replacement, show the complete desired content and supplied final URL. The current standard replacement behaviour includes display paths and pins rather than assuming every omitted part remains untouched. The proposal should make the resulting creative assessable.

Keep a status change separate from a URL or creative change. Replacing a paused ad's content should not silently enable it. If enablement is also requested, it belongs in its own clearly visible supported step.

The proposal states that no changes have been made yet and has a defined expiry. Only the Confirm and Execute action triggers the live edit path. The client can correct a mistaken target or URL while the request remains unexecuted.

For a wider sequence, preserve dependencies and the supported bounded request size. A coherent small proposal is easier to review than a long cleanup sentence containing several different effects. The goal is exact human understanding before the API request is sent.

Verify configuration without overclaiming

The execution path checks relevant authorisation and current settings before writing, then verifies the supported resulting configuration. A target may have changed since the proposal was prepared, so the original conversational assumption should not override current evidence.

A verified account edit can establish that the requested content or setting exists. It does not certify website uptime, successful checkout, provider approval or future advertising results. Each of those requires evidence suited to its own question.

If execution is not fully verified, inspect the current account state before retrying. The mutation may already have succeeded. Blind repetition is especially risky for creation, where a second request could create another ad instead of clarifying the first result.

Keep a confirmed rejection separate from uncertainty. An API response establishing that an operation was rejected supports a different next action from an incomplete readback. The handoff should state which condition occurred.

Record what was checked in plain language. The agency can tell the client that the intended account URL is now present while still awaiting a separate website or provider-state confirmation. This makes the success message accurate without diminishing the work actually completed.

Check later provider evidence

A destination finding reflects Google's published review evidence. After a website repair or account correction, use an appropriate later read to assess whether the relevant condition changed. Do not assume the verdict updates at the same instant as the repair.

Google's policy decision guidance describes correction and appeal paths. The app's destination read and creative builder are not a universal automatic appeal service. Use the applicable authorised provider workflow where that process is needed.

Keep the version and URL being reviewed clear. A later colleague may have changed the destination or creative after the original operation. The current provider finding needs to be interpreted against the actual resulting state.

Do not repeatedly rewrite the ad solely because the old finding remains visible. First establish whether the intended account change exists, what website work occurred and what the current provider evidence says. Activity is not a substitute for a defined next check.

If the finding clears, state the scope of the successful read. Another unread surface or unrelated destination issue can remain open. A resolved item should not become a blanket announcement that every campaign and page is healthy.

Measure performance separately

When the client asks about spending or delivery, use a compatible performance report with actual dates and scope. The destination finding does not itself contain a measurement of lost purchases, lost leads or avoidable advertising cost.

A period with reduced clicks can be observed alongside a destination issue, but their coexistence does not prove the issue caused every change. Budgets, offers, targeting and other account conditions may also differ.

Choose the outcome definition explicitly. Aggregate primary conversions, primary purchases and a named action can give different context. A client-specific business question should not silently switch between them before and after the repair.

For a before-and-after review, retain comparable dates and report basis where possible. Record other known changes. The agency can explain subsequent measured results without presenting the comparison as a controlled causal experiment.

Keep ratios based on their combined inputs, and leave unavailable values unknown. A missing conversion metric should not become a zero that supports a dramatic waste claim. Clear evidence definitions make the performance follow-up useful even when the commercial outcome remains uncertain.

Write a clear agency handoff

Write a short record that names the client account, affected item, available parent context, returned destination finding and next responsibility. Include any unread coverage. This is enough to orient another colleague without exposing unnecessary account or asset identifiers.

Separate evidence types. Google's published finding, the website owner's supplied test and the checked account edit are different facts. The recipient should be able to see which one supports each statement.

Describe the action status precisely. Proposed, approved, executed and independently checked are different stages. A pending provider condition or uncertain readback needs a next owner rather than an unexplained resolved label.

For the client, explain the practical effect in normal language. State which destination or creative was changed and what remains to be checked. Internal API terminology rarely helps the person decide whether the intended offer is ready.

Retain enough version context to continue later. If the destination changed after a website repair, record that as another event. This helps the team avoid applying an outdated correction or repeating a creation merely because the previous discussion is difficult to reconstruct.

Ask for an observation the recipient can actually supply

A website handoff is stronger when it requests a bounded observation rather than a general assurance. Ask the owner to identify the page it checked, the intended journey and what happened. If the page was changed, ask what changed and whether the intended route was assessed afterward. These are suggested human checks, not automatic tests performed by the destination reader.

Keep a failed reproduction useful. The owner may not observe the same behaviour that led to the provider finding. That does not invalidate either record. It means the agency has a discrepancy to investigate, with evidence about the current manual check and Google's published state. Avoid asking the owner to make speculative changes just to produce a reassuring completion message.

Resolve the intended destination before discussing replacement. If a service page is unavailable, a generic home page may open successfully but answer a different commercial need. The client should confirm whether it is an appropriate alternative. The assistant can help draft that question without inventing a page or silently changing the offer.

Specify the next authorised read. Once the website owner supplies a correction, the account specialist can check the relevant account configuration and provider evidence. If either remains unavailable, retain the uncertainty. This gives the next colleague a concrete starting point instead of a broad instruction to keep trying.

Use a small evidence record to connect the stages: original finding, intended destination, supplied website observation, any approved account operation and later provider state. It is an agency working method rather than a promise of a new automated incident system. Its benefit is preserving the meaning of each check across people who own different parts of the journey.

For an unused historical item, record the client's decision not to relaunch it. That can close the operational task while leaving the provider condition unchanged. It should not be labelled as a successful technical repair, because the evidence supports retirement of the intended use rather than recovery of the page.

Maintain a repeatable review routine

A practical routine links destination checks to relevant business events: launch preparation, website changes, asset updates and investigations into delivery. It does not need to describe the on-demand command as an unsupported scheduled crawler.

Give unresolved items a next event and owner. A website repair, a supplied final URL or a later provider-status check can move the task forward. Continually rereading unrelated account metrics rarely answers these specific questions.

Use broader monitoring signals for their intended purpose. A cost threshold or historical anomaly can prompt an investigation, but it cannot independently diagnose a broken destination. The focused read remains a separate step.

Preserve definitions across staff handovers. The next colleague needs the same account, target, evidence source and open question. A consistent format is valuable because it retains meaning, not because it forces every client into the same correction.

Use the agency audit guide for broader settings triage and Confirm and Execute for approved account changes. Keep these workflows distinct from the website owner's technical investigation.

Agency broken-link questions

Does the Links command visit the website?

No. It reads Google's published destination-related evidence from supported advertising surfaces. A new live page test or a customer-journey check is a separate responsibility.

Does no finding mean every page works?

No. It means no relevant findings were returned within successful checked coverage. Recent changes, unread surfaces and untested website behaviour still need their own evidence.

Does an enabled finding prove current spending?

No. Enabled configuration is not a performance measurement. Account-wide asset rows also do not independently establish every attachment's status. Retrieve supported performance evidence for a spending question.

Can a URL correction be applied automatically from the report?

The report does not authorise a live change. A supported requested edit needs an exact target and human confirmation. Website repair and provider review remain separate steps.

What should the agency keep after repair?

Keep the original finding, supplied website correction, checked account operation and later provider evidence with their relevant context. This supports a clear handoff without claiming that one check established every part of recovery.