---
title: "Why the contact email and website fields matter for App Store review"
description: "Contact email and website URL are compliance-critical fields under Apple and Google review guidelines, not incidental metadata."
excerpt: "A stale contact value can stall a review for reasons that have nothing to do with the listing copy itself."
source_url: "https://appstorehelper.com/guides/contact-email-and-website-field-compliance"
mirror_url: "https://appstorehelper.com/mirror/guides/contact-email-and-website-field-compliance"
section: "Editorial guides for app-store growth teams"
locale: "en"
published_at: "2026-08-08"
updated_at: "2026-08-08"
reading_time: "3 min read"
tags:
  - "App Store review"
  - "compliance"
  - "contact info"
  - "submission"
---

## Direct answer

The contact email and website URL fields on a project aren't just metadata — Apple and Google both require accurate, working support contact information as part of listing review, and a submission with a placeholder or outdated contact detail can be rejected on that basis alone regardless of how strong the rest of the listing is. Keeping these fields accurate is a compliance checkpoint, not an optional detail.

## Why this is a review risk, not just a UX nicety

Both platforms' review guidelines expect a real, reachable way for users and reviewers to contact the developer. A contact email that bounces, or a website URL that 404s, is the kind of small technical failure that stalls a submission for reasons that have nothing to do with the quality of the copy or the app itself — it's an easy rejection to avoid and an unnecessary one to trigger.

## These fields also feed generated support-facing copy

Beyond compliance, the contact email and website fields can appear in generated listing content that references support channels. If the project's contact information is stale, that staleness propagates into any copy that references it — another reason to treat these fields as living data that needs to match the app's actual current support setup, not a one-time entry from initial project setup.

## Update them when support infrastructure changes

If a team switches support email providers, moves to a new website, or changes its support process, the project's contact fields should be updated at the same time — not discovered as stale only when a review gets rejected or a user complaint reveals the old address no longer works.

## Common mistakes

- Using a placeholder or personal email address instead of the app's actual support contact.
- Leaving an old website URL in place after a domain migration, which both breaks review compliance and sends users to a dead page.
- Treating these fields as one-time setup instead of information that needs to stay current with the app's real support infrastructure.

## Checklist

1. Confirm the contact email is a real, monitored address tied to the app's support process.
2. Confirm the website URL resolves and reflects the app's current site, not a retired domain.
3. Re-check both fields whenever support infrastructure changes, not just at initial project setup.

## Operating rule

Treat contact email and website URL as compliance-critical fields, not incidental metadata — a stale value here can stall a review for reasons that have nothing to do with the listing copy itself.