We found a concrete problem while reviewing one of our own app ads: the final destination was an App Store link that returned a 404 error. The campaign still contained its headlines and images, but the customer could not reach the advertised listing. This guide turns that finding into checks a small studio or business can repeat before promoting an app.
1. Verify the public listing separately from the build
A successful build, an uploaded archive, and a review submission are different milestones. None alone proves that a customer can download the app. Open the exact store listing in a browser where you are not signed into a developer account. Check the product name, developer, icon, supported devices, and target country. If the listing is unavailable, record that result and hold download advertising.
Test the full address copied into the campaign. A product name that looks right is not enough: an incorrect numeric app ID can send a visitor to an unavailable page or a different app. Keep the verified listing address in one release record and copy it from there.
2. Follow the complete link on a phone and a computer
Start from the link the customer will actually click, including any tracking parameters. Follow redirects and confirm that the final page opens without a sign-in requirement, certificate warning, missing-page message, or endless loading screen. A desktop page that works does not prove the phone route works.
For a technical check, inspect the HTTP response and final address. A 404 indicates a missing destination. A 200 is useful evidence, but still inspect the rendered page: some sites return 200 for an error screen. Test the primary action as well. A readable page with a broken download button is an incomplete journey.
Google requires ad destinations to function and be accessible to its crawlers. Do not serve a special page only to an ad crawler or hide a broken destination behind redirects. See Google Ads destination requirements.
3. Match every promise to what the visitor can do today
If the ad says “Download,” the destination should offer the advertised download. If the app is a development preview, use language such as “Explore the app” and explain its availability on the page. A preview page should not imitate a released store listing or promise immediate installation.
Check headlines, descriptions, sitelinks, and the call to action together. Remove a newsletter promise when the destination has no newsletter form. Describe the actual product rather than adding unsupported claims such as “expert,” “guaranteed,” or “instant.” For a pet-care product, explain educational limits and the role of veterinary care.
4. Give an unavailable app a useful information page
A product information page can explain the app while a store listing is unavailable. State the current availability near the beginning. Describe its intended audience, main tasks, limits, privacy information, and a real contact route. Include actual product screenshots when you have verified captures; label concept artwork clearly.
The page should help someone decide whether the product fits their need without requiring a download or personal information. Link to related guidance the visitor can use now. For a planning-stage product, explain what is planned and what is currently usable separately. Update the page when public availability changes.
5. Keep a small release record
Use one row per destination. Record the exact URL, test date, device, country, response, product identity, and result of the main action. A failed check needs an owner and a next step. Recheck after a store availability change, domain migration, redirect change, or campaign URL edit.
Worked example: unavailable store listing
Observed: the final App Store URL returns 404. Decision: pause the campaign; verify the app’s public release status. Interim route: use the studio’s working product information page with preview wording. Evidence needed before download advertising: a public listing for the correct app and a successful customer download journey.
Download the release-link worksheet (plain text). It contains the fields above and a repeatable checklist. Keep private customer information and authentication tokens out of the worksheet.
Before you request another ad review
Save the repaired destination and accurate copy, then verify the saved settings. A pending review is not approval, and approval is not proof of customer conversion. Keep a paused campaign paused until you are ready to launch with its budget. Website AdSense approval is a separate process from approval of paid Google Ads.
If you are preparing a new product, use our app brief builder to define the first customer task and its acceptance checks. For an existing broken journey, send a maintenance inquiry with the public URL and a description of the failure.