App Store Connect support URL and marketing URL guidelines – complete guide

Are there guidelines for the support URL and marketing URL fields in App Store Connect?

Name: PTKD
Availability: InStock

Written by Laurens Dauchy

App Store Connect support URL and marketing URL fields look simple, but they’re common rejection points. In my experience shipping and reviewing dozens of iOS releases, Apple expects URLs that help real users—fast, clear, and live. If you follow a few practical rules, you’ll pass review smoothly and reduce support noise.

Here’s the short answer: yes, Apple has clear expectations even if they’re not all in one place. Your support URL must load a responsive page where users can get help immediately—think contact options, FAQs, and privacy information. Your marketing URL must describe the app with screenshots, value props, and up‑to‑date details. I’ll show the exact do’s and don’ts I use with teams.

What does Apple expect in the support URL?

The support page should act like a well‑marked exit in a stadium: if users are lost, they can find help in one step. My checklist keeps reviewers happy and users confident.

Immediate help options: visible contact link or form, and a reachable email.
Self‑service: short FAQ covering sign‑in, purchases, cancellations, data requests.
Privacy: link to your privacy policy and data request instructions.
Availability: page loads without login, no paywall, no 404, HTTPS only.
Mobile friendly: responsive layout; works on iPhone sizes.

What belongs in the marketing URL?

Think of the marketing page as your storefront window—people should “get it” in five seconds. Reviewers check whether this page matches the app they see.

Clear product overview: what the app does, who it’s for, and why it’s useful.
Visuals: current screenshots, short demo GIF or video, feature highlights.
Consistency: name, icon, and messaging aligned with App Store listing.
Policies: link to privacy policy and terms for credibility.
Up‑to‑date: no “coming soon” placeholders; avoid lorem ipsum.

Common rejection triggers (and how I fix them)

Support URL leads to a generic homepage with no help → add a /support page.
Support email missing → add a visible mailto, and confirm the inbox is monitored.
Marketing page talks about a different product → align copy and images.
Pages blocked by robots/noindex → allow access to the two URLs.
Broken anchors or 404s → run a quick link checker before submission.

Short walkthrough

Support URL: the structure I ship with teams

Use this minimal structure. It’s quick to build and passes review reliably.

Headline: “Need help with [App Name]?”
Buttons: “Contact support”, “FAQ”, “Privacy requests”
FAQ bullets: sign‑in, billing, subscription cancellation, data deletion/export
Footer: legal links, company address, support hours

Marketing URL: fast, credible, conversion‑ready

Your marketing page should answer three questions at a glance: What is it? How does it help me? What proof do you have?

Hero: single sentence value prop app screenshots.
Features: 3–5 bullets with benefit‑led phrasing.
Social proof: quotes, ratings, or usage claims you can back up.
Privacy: link to policy and data practices.
CTA: “Download on the App Store” or “Try it free”.

Start with a quick risk scan

I use PTKD to catch privacy and security issues that cause rejections. It spots leaky permissions, weak TLS, trackers, and unstable SDKs before reviewers do.

Start free scan

No credit card. Results in minutes. Trusted by indie teams and enterprises.

Settings that matter for GDPR/PDPA/GR71

For teams in Europe (GDPR) and Southeast Asia (PDPA, GR71), these details materially reduce compliance risk and smooth review:

Data rights link: how users request export or deletion (GDPR Art. 15–20).
Contact method: working email for DPO/support, not a dead form.
Tracker disclosure: summarize analytics/ads SDKs used.
Consent banner: region‑aware if you process personal data.

Helpful background: OWASP Mobile Testing Guide, Apple Review Guidelines, and Google Play User Data policy for contrast.

Examples that pass (and why)

Support URL examples

support.example.com with contact, FAQ, and privacy links visible up top.
example.com/help with billing and account recovery steps.

Marketing URL examples

example.com/app with screenshots, short demo, and aligned copy.
example.com/products/appname with changelog and data practices.

Table: support vs marketing URL checklist

Item	Support URL	Marketing URL
Purpose	Help users resolve issues	Explain value, drive installs
Must include	Contact, FAQ, privacy link	Overview, visuals, CTAs
Access	Public, no login	Public, current content
Gotchas	404, dead email, paywall	Mismatched branding

Implementation footguns I see often

Putting the support link inside a logged‑in dashboard.
Using a LinkedIn page as “marketing” (weak signal for reviewers).
Forgetting privacy links on both pages.
Copy not matching your App Store screenshots or description.

Internal resources to help you ship faster

Key takeaways about App Store Connect support URL and marketing URL

Keep it simple and human. A support URL that actually solves problems and a marketing URL that clearly explains value will pass review and reduce churn. Align copy, keep links live, and make privacy easy to find.

If you operate in GDPR/PDPA/GR71 regions, highlight data rights and provide a working contact. These steps measurably reduce rejections and user complaints.

FAQ

Can I use my homepage as the support URL?

You can, but only if it clearly exposes help options above the fold. A buried contact link is a common rejection reason.

Does Apple require a custom domain?

No. A subpath like example.com/support is fine. The page must be public, responsive, and accurate.

What if my marketing page is not ready?

Publish a simple, truthful landing page with screenshots and benefits. Avoid placeholders like “coming soon.”

WRITTEN BY LAURENS DAUCHY - FOUNDER OF PTKD — 5 October, 2025