Google Ads broken-link checks for small businesses: find reported destination problems and organise the repair

Start with the customer journey

A paid click should lead to the experience the advertisement promises. For a small business, a destination problem can interrupt the route from an interested visitor to an order, enquiry or booking. Start the investigation with that intended journey. Which offer did the ad describe, which page should the visitor reach, and what should they be able to do there? A URL string is only one piece of that journey. An apparently normal address can still lead to the wrong offer or a page whose next step does not work.

The word “broken” can cover several different observations. A page may return an error, redirect incorrectly, be unavailable to a relevant visitor, or fail a provider's destination requirement. It may load successfully while its form or checkout fails. The appropriate evidence and remedy differ in each case. Describe the specific observation before proposing a fix. This helps the owner avoid changing ad text to repair a server problem or assuming a successful page load proves that the business can fulfil the advertised purchase.

The practical outcome is a clear task with a responsible person and a later check. The business may need website work, a supported account edit or both. A report by itself does not repair either one. Nor does a pause restore the customer journey; it changes advertising eligibility while the underlying task remains open. Keep those distinctions visible from the beginning. A useful broken-link routine protects customers from an unsuitable journey while giving the owner enough evidence to decide what should happen to the relevant advertising.

Distinguish three kinds of destination evidence

First, account configuration can reveal which address or tracking setting an advertiser supplied. That tells you the intended configuration, not whether the live page works. Second, provider-reported policy evidence can reveal a destination issue noticed during the provider's review. That tells you the reported reason and affected advertising object. Third, a live journey check can establish what a particular browser or visitor experienced at a particular time. These sources can support one another, but they do not prove the same thing and should not share an undifferentiated “passed” label.

A provider result can remain useful when a website has since changed, but its timing and purpose matter. A page that broke recently may not yet have a reported policy issue. A repaired page may await another provider review. A successful manual page load may occur under different circumstances from the provider's reported failure. The right response is to gather the evidence required for the decision and state what each observation establishes. Do not choose whichever result sounds most reassuring and discard the unresolved discrepancy.

Similarly, an HTTPS check concerns the address scheme, and a policy approval concerns reported eligibility. Neither establishes a completed order or a working form. A customer-journey check should describe its actual coverage rather than becoming a blanket certification of the website. The policy-monitoring guide explains related serving and review distinctions. For broken-link work, the core habit is to keep the configured address, reported provider state and observed journey separate until the evidence supports a coherent explanation.

Understand the current provider-based check

The current ppctor links tool reads destination-related policy findings from Google Ads. It does not fetch every advertised page or run a browser through every checkout. Its destination reader covers ads, account assets and Performance Max asset-group relationships, preserving the reported destination-topic reasons. That scope makes it a focused way to ask what Google has reported about destinations in the connected account. Describe the result accordingly: reported destination findings, not a freshly crawled inventory of every broken page on the business's website.

This approach has an important timing limit. It follows provider-reported review evidence. A new website fault may not yet appear, while an older finding can still require interpretation after a repair. The tool is therefore useful for inspecting advertising-side destination concerns, but it cannot rule out a newly broken journey merely because the result has no findings. If the owner has direct evidence that a page failed, investigate that observation separately instead of dismissing it because the provider-based report looks clear.

The reader obtains the supported surfaces independently and retains successful findings when another surface fails. It reports which surfaces were unread. This gives a meaningful partial answer without turning unavailable evidence into zero. It also avoids sending large numbers of page requests just to create a conversational report. That efficiency is valuable, but it does not broaden the check's meaning. The owner should understand exactly which provider evidence was read and when a separate website or visitor test is required to answer the actual question.

Choose an account and relevant advertising scope

The channel's connected Google Ads account establishes the initial scope for a Slack check. Confirm that it corresponds to the business or market under discussion. A company can have several accounts, and a familiar channel name does not prove every one of them is included. If the account is no longer reachable, the assistant should explain the connection issue rather than return a false clean result. A successfully inspected account is a necessary foundation for interpreting any list of affected destinations or planning an account edit.

Within that account, identify the offer or campaign that matters to the decision. The initial check can surface broader findings, while a follow-up explains the relevant rows and parent context. Do not assume a campaign name alone identifies a unique destination. Several ads or assets can point to different pages, and one page can be used by several targets. A report of affected advertising objects and a deduplicated list of website addresses are different products. State what is being counted or described before using the number to judge the size of the incident.

Current destination findings also differ from historical spending. A campaign that previously sent traffic to a page may now be paused, and its past cost remains part of the selected performance period. If the owner asks how much money was spent during a suspected outage, obtain the appropriate dates and performance scope. A current policy finding does not establish the outage's start time or how every past visitor experienced the page. The investigation needs that timing evidence before estimating any commercial impact.

Read ad findings with their parents

The current ad destination reader includes supported non-removed ads and their non-removed parent groups and campaigns. It retains destination-related policy topics along with recognisable creative information. For a finding, the owner should see the ad context and its campaign and ad group. Similar headlines can appear in several places, so the parent chain is important. It helps the owner identify the intended target and prevents a later edit from being applied to a different ad that happens to share a phrase.

The enabled classification for an ad finding requires the ad, ad group and campaign all to be enabled. An enabled ad inside a paused campaign is not classified the same way as one with all those parent settings enabled. This is a configuration distinction, not proof of impressions or current spending. The provider's destination issue may itself prevent serving. Avoid calling the list a set of ads definitely wasting money today. The evidence shows reported problems and the relevant status combination, while actual activity requires a scoped performance read.

When preparing a remedy, inspect the full relevant target state rather than relying solely on the compact finding. A reported reason can identify the investigation, but the desired final URL or complete creative may need to be obtained from the owner or current account evidence. The proposal should explain the actual intended change. It should not invent a replacement landing page based on a business name or assume that a parent campaign's website is the correct destination for every ad in the group.

Interpret account-wide asset findings carefully

The links reader queries account assets directly to see destination-related policy findings that can affect assets used at different attachment levels. This matters for sitelinks and other destination-bearing assets that do not all appear through one campaign or group relationship. A returned asset name can identify useful content for investigation, but its account-wide row does not necessarily provide the complete set of attachments. Do not invent a parent campaign where the returned evidence does not establish one. The owner may need additional relationship evidence for an attachment-specific change.

An asset resource does not have the same enabled or paused setting as every relationship that uses it. The current reader puts standalone asset findings in its enabled-side output because the direct asset evidence does not carry those relationship statuses. Interpret that convention honestly. It keeps reported issues visible; it does not prove that each asset is currently attached to an enabled campaign or generating traffic. A summary should not turn the convention into a commercial claim that every returned sitelink is actively spending.

If the owner asks to repair or remove an asset, clarify whether the operation concerns the content itself or a specific attachment. Reused content can affect several advertising contexts, while detaching one relationship has a narrower effect. Supported tools and current target evidence determine which operation can be prepared. Preserve that distinction in the proposal and result. A readable name and relevant parent context should help the owner recognise the change, while precise internal resource identity remains behind the scenes for execution.

Include the Performance Max structure

Performance Max uses asset groups, so a destination investigation cannot assume the Search ad-group structure applies everywhere. The current links reader has a separate asset-group relationship query. It returns the relevant campaign and asset group context with reported destination topics. An account using Performance Max can therefore have meaningful findings even when a conventional ad query returns no affected rows. Explain the group hierarchy correctly: an asset group belongs to its campaign, and it should not be labelled as a parent ad group.

The enabled-side classification for these findings uses the reported campaign and asset-group settings. As with other findings, that classification does not independently prove current delivery. The reported policy topic is another part of the evidence. If the business has several asset groups, each can have different content and targeting context. A finding on one relationship should not be presented as proof that every group has the same destination problem. Group the results by actual parents when the owner asks where the issue occurs.

Keep product destinations and listing choices distinct from the creative relationship evidence. A manually excluded product is a targeting decision; a Merchant eligibility issue is an inventory state; a destination-topic finding on an asset relationship is the scope this reader reports. A feed-wide product-page crawl is not established by the links command. If the user's concern is a particular advertised product or product feed, identify the additional evidence required. Do not describe one creative finding as an inventory count or assume that changing listing inclusion repairs a product page.

Separate enabled, paused and removed objects

Paused objects can still deserve a destination check before they are resumed. The current reader excludes removed objects on supported ad and group surfaces, but keeps relevant paused or disabled contexts in its separate non-enabled list. That is useful for planning. An owner might otherwise enable an old campaign and discover only afterwards that its destination changed during a website migration. Treat a paused finding as a readiness task rather than evidence that the target currently causes spending.

Enabled parent settings mean the configured status allows that part of the account to participate, subject to other requirements. A reported destination restriction can still stop or limit serving. If the owner asks whether an affected target has spent recently, retrieve cost for the specified period. Do not infer it from the enabled label. Conversely, historical cost can belong to a target that is now paused. A status-based attention list and a period-based spending report answer different questions and should not be expected to have identical rows.

Before resuming a target, review the actual intended offer and page as well as the relevant provider state. A successful enable operation does not override destination policy. A repair note does not prove that Google has reviewed the repaired content. If the business asks for an interim pause while work is completed, prepare the exact supported status action with its parents and approval. Later resume the selected target only through a deliberate new decision, instead of assuming the original pause created recurring permission to alter its status.

Keep unread surfaces visible

A complete-looking list can be misleading if one of its sources failed. The current destination collector names unread ad, asset or asset-group surfaces while preserving the findings from successful reads. This distinction should survive every compact summary. “No findings in the surfaces read” does not mean “every destination is working.” A failed read provides no healthy-state evidence. The owner needs to know what was observed and what could not be inspected so that the next question can address the gap.

Partial coverage should not stop useful work on a known problem. If the ad reader identifies a reported issue, the owner can begin investigating it while another surface remains unavailable. Record the missing check as a separate task. Do not claim account-wide clearance after repairing only the known row. Likewise, do not throw away valid findings just because another source failed. The goal is a useful bounded result with honest limitations, rather than either blanket reassurance or a total absence of information.

Connection failures, provider errors and unavailable surfaces need different explanations from an empty successful result. If reauthorisation is required, give the appropriate connection path. If an individual surface is temporarily unread, name it and obtain a later valid check when needed. An old result can remain conversation context, but should not silently become a current observation. This preserves the business's ability to act on evidence and prevents a user from approving further advertising based on a fabricated assertion that every destination passed.

Read the reported reason before choosing a remedy

Google's destination requirements distinguish working, matching, crawlable and accessible destinations, alongside destination-experience requirements. These are different concerns. A page returning a failure, a redirect mismatch and an accessibility restriction do not all have the same repair. Use the actual reported topic to direct the investigation. This brief distinction does not replace the relevant policy explanation or a technical check of the affected page.

The current reader selects destination-related topic identifiers, including destination, landing-page and URL topics, and presents their readable reasons. A returned finding is therefore broader than a simple HTTP-error list. It can describe a destination-policy concern even when the owner's browser loads a page. The message should not convert every topic into “404” or claim to know the exact technical fault from a broad reason label. Inspect the detailed provider explanation and relevant site behaviour before choosing an implementation change.

If several topics occur on one target, consider whether they reflect one underlying task or several. The owner may need to repair a redirect and also revise the page's content. A row count is not necessarily a task count. Keep the target, reported reasons and next check together. If the cause is still unclear, ask for the evidence that will resolve it: the intended landing page, observed error, recent website change or provider detail. A specific investigation is more useful than an automatic generic URL rewrite.

Treat HTTPS and URL syntax as separate checks

An HTTPS address is a sensible expected form for a public landing page, but its prefix alone does not prove the page works. The audit's final-URL HTTPS check looks at configured address strings. It does not perform a full live journey test. A proposal to change a destination must therefore consider the intended page and supported operation, rather than assuming that substituting one scheme for another repairs every reported issue. A page can use HTTPS and still be unreachable, unsuitable or broken after loading.

The dedicated bulk HTTPS rewrite action is currently unavailable in the conversational edit catalogue because the required live destination verification is not established. Ordinary ad creation can normalise a supplied domain to an HTTPS URL as part of preparing required fields, but that is a syntax convenience. Do not present it as a reachability check. The user still needs to supply the correct public landing page, and the provider's later review remains separate from the account's acceptance of a syntactically valid creation request.

When an address appears wrong, confirm the exact intended destination with the owner before preparing a supported change. A homepage may be public and reachable while failing to match a particular offer. A product page may have a new path after a site update. The correct remedy should preserve the business intent and relevant tracking requirements. Do not infer the right URL from a keyword or replace several pages with one generic domain simply to make their prefixes look consistent.

Review the final destination and redirects

A redirect can be legitimate, but the visitor's final experience and the ad's stated destination still need to align. Website migrations, language selection and product-path changes can alter that route. Inspect the actual intended page and relevant provider reason. A successful first response from a supplied address does not establish that every later redirect leads to a useful page. The website owner should verify the path that matters to the visitor, rather than ending the investigation after seeing that the original domain responds.

If the site has moved an offer, decide whether the advertiser should use the current intended page directly or retain an appropriate redirect. That is a business and implementation choice requiring the actual site facts. The assistant should not remove parameters, rewrite paths or choose another domain without evidence and permission. A URL can carry information required for a booking, selected product or tracking arrangement. A tidy-looking shortened address can silently change the journey. Explain the desired final configuration before applying a supported account edit.

Record migrations and planned redirect changes in the advertising handoff. Name the affected offers and the date they changed. A later reported destination issue can then be investigated against a known event rather than treated as an unexplained account problem. If several targets use the same page, identify their actual usage before assuming one edit repairs all of them. Shared site work may resolve one underlying fault, while each relevant ad or asset still needs its configuration and provider state checked.

Include the actual tracking path in the investigation

A visitor may encounter more than the plain final URL stored on an ad. Relevant tracking templates, suffixes and parameters can affect the route and measurement. If the reported concern or observed failure involves that path, inspect the actual configuration and intended behaviour. Do not conclude that the journey is healthy solely because copying the unexpanded destination into a browser works. A test that bypasses the problematic part of the route can provide useful evidence about the page while leaving the original advertising issue unresolved.

Changing a tracking setting can affect measurement or external systems, so do not clear it merely because it looks technical. The owner may have an intentional integration. A supported account-template action should be proposed only after its scope and consequence are understood. Account-level changes can reach beyond the single ad that prompted the question. Conversely, a specific ad destination edit may leave a parent-level tracking issue untouched. Match the chosen operation with the verified cause and show the exact action in the approval message.

Keep destination functionality and analytics collection as related but separate checks. A page can load while an attribution parameter is lost, and a tracking event can fire while a form fails to produce an enquiry. The business should know which symptom is being investigated. If the assistant needs current account configuration, obtain that evidence. If the next task is explaining an already retrieved setting or drafting a handoff note, reuse the existing record. Avoid repeating broad provider reads that do not resolve the actual point of failure.

Check the relevant visitor circumstances

A destination can behave differently under different visitor circumstances. The relevant device, location, authentication requirement or browser state can matter to an observed fault. Describe the circumstances actually tested rather than claiming that one successful visit establishes universal accessibility. The current provider-based links command does not run those live visitor tests. If the owner reports a mobile-only problem or a page that requires an unexpected login, route the investigation to the website evidence needed to reproduce that specific experience.

A website manager can compare the expected public journey with the observed result and inspect any relevant site restrictions. The goal is consistent legitimate accessibility for intended visitors, not showing the provider a special version that conceals a broken journey. If a security or access rule is involved, make a deliberate implementation decision using the actual system's needs. Do not advise disabling every protective setting simply to eliminate a reported label. The repair should address the demonstrated restriction while preserving the business's required controls.

Record the time and circumstances of a reproduced issue so later checks can be compared meaningfully. A page that worked at one moment and failed at another may have an intermittent problem rather than a contradiction. A provider report may also refer to a different observation time. Keep these facts in the task note and avoid turning them into an invented outage duration. The owner needs a clear next test and responsible person, not a confident generalisation based on a single browser result.

Test the commercial next step separately

Loading the intended page is only the start of a useful customer journey. A shop needs an order path that works for the advertised product. A service business needs an enquiry or booking route that reaches the appropriate person. A page can return ordinary content while a selected variant is unavailable, a form fails or an appointment option is missing. Those are commercial journey issues, even if the provider has not surfaced a destination-policy finding. Assign the relevant test explicitly when the business has evidence of such a problem.

A meaningful test should match the intended action and have appropriate authorisation. It need not create a real charge or send unwanted customer communications merely to check a page. The website owner can choose a suitable test arrangement and inspect the resulting records. The current links tool does not perform that work, so its report should not claim that checkout, payment, form delivery and fulfilment all passed. State the actual coverage of the manual or implementation check used to resolve the task.

Separate the journey result from conversion measurement. A successful booking may not be recorded correctly in an advertising platform, while a recorded event may not establish that a usable booking reached the business. If the owner is investigating weak outcomes, these distinctions help identify the next evidence. The wasted-spend guide discusses measurement and business intent. A destination review can support that investigation without pretending that a clean policy report proves every part of the commercial funnel is working.

Follow an invented shop's destination incident

Consider an invented shop, Birch Table Kitchenware, after a website category update. Its reported destination check finds one issue on an RSA in an enabled Search campaign, one sitelink asset issue at account scope and one finding in a paused Performance Max asset group. The ad surface and asset-group surface were successfully read, while another required scope might be unavailable in a separate run. These are illustrative observations, not a customer incident or evidence of actual lost sales. Their meaning depends on reported reasons, scope and the intended offers.

The owner recognises the Search offer and says its old page now redirects to an unrelated category. The website manager verifies the intended new page and the redirect behaviour. The sitelink needs its actual usage checked because the standalone asset finding does not prove a particular enabled campaign attachment. The paused group is a future-readiness task, not evidence of present spending. A useful response separates these tasks instead of announcing three broken pages that are definitely wasting money across the account.

If the owner asks to update the RSA to the verified intended page, the assistant prepares the supported edit with the creative's actual parents and relevant field behaviour. The owner confirms it. A verified result establishes the account change, while the website repair and the provider's later destination state receive separate checks. If the user then asks about past impact, obtain the relevant outage timing and performance evidence. Do not multiply the current finding count by a guessed click cost or call all historical campaign spending recoverable waste.

Prioritise by purpose and consequence

Start with the offers the business is relying on now or intends to launch soon. A reported issue on a central booking page may deserve prompt attention, while an old paused offer can be reviewed before its next use. Use actual campaign purpose and available activity evidence to make that distinction. A raw finding count cannot establish urgency. It can also overstate the number of unique technical faults if several advertising objects point to the same affected page. Explain the counted scope and the suspected task relationship.

A known website problem can deserve attention even if the provider check is clear. The owner may have a reproduced failure or customer reports. Conversely, a reported issue can remain unresolved despite a successful ordinary browser visit because the relevant conditions or provider reason differ. Prioritise the demonstrated customer consequence and the evidence needed to resolve it. Do not wait for every possible source to agree before assigning a precise task, but also do not claim universal repair from a single favourable observation.

If immediate protection is needed, the owner may request a supported pause or destination change. That is a separate advertising decision. Explain which target will be affected and which business repair remains open. Pausing every campaign can be unnecessarily broad when the problem belongs to one offer; keeping all delivery unchanged can be inappropriate when an important journey is known to fail. The correct scope comes from the evidence and the owner's intention, rather than a universal response applied to every destination finding.

Assign website and account tasks separately

The website manager and advertising owner can share a problem without sharing the same controls. The website manager may repair a path, redirect, access rule or form. The advertising owner may update the relevant configured destination or temporarily change delivery. Assign each task explicitly. Otherwise, one person can finish their part while the other assumes everything is resolved. A message saying “the link is fixed” needs enough context to show whether it means the page works, the account points to it or the provider has reviewed it.

A practical task note includes the recognisable target, relevant page, reported reason, observed symptom, intended result and responsible person. Keep unnecessary account identifiers and customer details out of the client-facing handoff. Include timing where it affects interpretation, such as a migration date or a planned launch. The note should identify the next evidence needed to close the task. For example, a website test and a fresh provider-state check can both be required without pretending that either one replaces the other.

Agree who will make the final advertising decision once the evidence is available. A developer's page repair is not automatic authority to resume every affected campaign. An adviser who prepares a proposal may not be the authorised connected owner who can confirm it. The business should deliberately decide whether to use the repaired destination and which targets should participate. A clear handoff protects the account from premature enablement and prevents an unresolved readiness task from lingering because everyone assumes someone else owns the next step.

Use Slack for the reported check and follow-up

The current /ppctor links command inspects reported destination findings for the connected account. An ordinary conversation can ask the assistant about a particular offer, target or concern and use the available evidence appropriately. Keep the request clear: are you asking what Google reports, which configured page an ad uses, or why a live customer journey failed? The assistant should choose the relevant source and state its coverage. It should not claim a browser test when it only queried reported policy topics.

Follow-up questions can inspect the known result: which parent the target belongs to, which surfaces were unread and what the reported reason means. A detailed diagnosis may need additional provider or website evidence. If the user only wants the returned findings explained more plainly, re-reading the entire account is unnecessary. If an edit or repair occurred and current provider state matters, a fresh check is justified. Preserve the actual evidence basis so the conversation stays coherent instead of treating every reply as a new unrelated incident.

The assistant can help draft a website task or explain the difference between syntax, reported eligibility and customer experience without making another live call. Creative or explanatory work can use context already in the thread. A request for an actual account change enters the proposal flow with valid targets and required fields. A request for an explanation should remain an explanation. This keeps Slack useful for collaborative troubleshooting while ensuring that an owner's concern about a broken page does not itself authorise unrequested account edits.

Present the affected targets clearly

A destination summary should name the affected ad or asset, its actual known parents and the reported reason. Separate the enabled-side and non-enabled contexts without implying either list establishes spending. Include unread surfaces near the result, even when the preview is long. A readable label is better than a raw resource name for the owner, while the execution system retains internal identity where needed. If names are ambiguous, the assistant should ask for the distinguishing context instead of guessing a target.

List each proposed task or edit on its own clear row or section. The website repair, destination update and later status decision can be related, but should not merge into one technical paragraph. An account-level asset finding with no resolved attachment must not invent a parent. An RSA belongs to an ad group and campaign; a Performance Max relationship belongs to an asset group and campaign. Correct hierarchy and understandable action labels should hold across report summaries, approval proposals and execution receipts.

When the result is a preview, say that additional findings exist instead of presenting the displayed examples as the total. Keep counts tied to their actual unit: reported advertising occurrences, unique configured addresses or resolved pages. These units can differ. Avoid showing internal implementation names or provider metadata that does not help the owner decide. The message should make the known problem and next step clear while retaining material limitations. Removing clutter should improve comprehension, not remove the coverage warning that makes the report honest.

Prepare the supported account change

An account change should address the owner's agreed task and the verified target. For an RSA destination update, the current supported edit may involve the full desired creative and final URL fields. Inspect the operation's defined behaviour so related fields are not accidentally cleared or changed. For a status change, identify the target and exact intended status. The assistant should not substitute a broad campaign pause for a requested single-ad edit merely because it is easier to prepare or because both might reduce exposure.

The proposal must show the understandable target, actual parents and exact steps. Confirm and Execute authorises the prepared live operation for the connected owner. Before confirmation, no live edit has been made. The proposal expires after fifteen minutes, and relevant current state is checked again before execution. These safeguards matter when a website manager or another operator has changed the account since the investigation began. An old proposal should not silently overwrite a newer correct destination or select a different target without renewed agreement.

Multi-step operations need valid dependency order and honest boundaries. The tool can use local capability and dependency information to prepare supported work, while live facts still require the appropriate checks. Do not promise that unrelated operations are universally atomic or automatically reversible. If some requested work is outside the supported tool, state that task explicitly. The approval guide describes the handoff. A destination incident should follow the same precise flow rather than bypassing confirmation because the word “broken” sounds urgent.

Verify the edit, repair and provider state separately

The interface should show a visible change-in-progress state after a valid confirmation. The final result should distinguish a verified account edit from a write accepted without complete result verification. A verified receipt for a final URL change establishes the requested configuration, not a successful checkout or a completed provider review. The owner should understand what the receipt proves. Website testing and the provider's reported destination state remain separate checks where they are required to close the incident.

If the write outcome is uncertain, inspect the relevant target before issuing another mutation. Do not automatically replay a request merely because the final message lacked complete verification. The first operation may already be present. This matters particularly when a remedy creates a new asset, where repeated requests could introduce duplicates. Once current state is known, the next step can be prepared deliberately. An honest uncertain result with a safe state check is more useful than a false failure claim that encourages the owner to click or request creation again.

After the page and account configuration are repaired, review the actual customer journey under the relevant circumstances and obtain current provider evidence if readiness depends on it. Delivery can also depend on parent status and other account conditions. A clean destination result does not guarantee impressions or business outcomes. Later performance should use a defined period and selected outcome population. Keep other website or advertising changes in the interpretation so an improved ratio is not automatically attributed to one URL edit without supporting evidence.

Maintain the destination record through website changes

Website migrations, product removals, promotion endings and booking changes are useful moments to review advertising destinations. Give the advertising owner advance notice of changes that affect active offers. A small business does not need a complicated register, but it benefits from knowing which important pages support which offers and who maintains them. That record makes a reported issue easier to investigate and helps prevent old paused campaigns from being resumed against pages that no longer fulfil their promises.

Use provider-based checks for their actual purpose and separate manual journey checks when needed. Do not describe an on-demand links command as a continuous website uptime service. The business can define its own review routine around launches and significant changes. A check's value comes from useful coverage and a completed response, not simply frequency. Repeatedly asking for the same report while leaving the website task unresolved does not improve the customer journey. Close the specific task and retain the evidence that supported that decision.

Keep a concise history of the incident: reported finding, reproduced symptom, intended repair, account edit if any, responsible people and closure checks. Preserve unread coverage as a separate item until it is resolved. If the owner chooses to retire an offer instead of repair its journey, record that decision and the supported account action separately. The result is a coherent operational record that explains what the business changed and why, rather than a series of reassuring messages whose evidence and scope cannot be reconstructed later.

Answer common broken-link questions

Does the links command test every page live?

No. It reads destination-related findings reported by Google across its supported ad, asset and asset-group surfaces. A live website journey test is a separate task. A page that broke recently may not yet have a provider finding.

Does an enabled-side finding prove current spending?

No. It reflects the reader's status classification, with a separate convention for standalone assets whose attachment status is not present in that query. Actual cost requires period-specific performance evidence. A policy restriction can also prevent serving despite enabled parent settings.

Will adding HTTPS fix a reported problem?

Not necessarily. Address syntax does not establish reachability, correct content, accessibility or a working form. Confirm the intended page and actual cause. The dedicated automatic HTTPS rewrite is unavailable without the required destination verification, while ordinary URL normalisation remains a syntax convenience.

When can the incident be considered resolved?

When the required website work, intended account state and relevant provider check have the evidence needed for the business decision. A verified account receipt proves its stated edit, not every other stage. Keep uncertain writes and unread surfaces open for a safe follow-up instead of turning missing evidence into success.