How to Create Custom Product Pages That Match Search Intent

A custom product page should not exist because you want another design.

It should exist because one group of users needs a clearer answer than your default App Store page can give them.

Imagine a meal-planning app with three real use cases:

• quick family dinners
• low-cost weekly meal plans
• high-protein recipes

The default page can mention all three. It cannot make each one the main promise at the same time.

A custom product page can show the budget-conscious user screenshots about price, shopping lists, and reducing food waste. A second page can show protein goals, nutrition breakdowns, and meal prep. Both pages lead to the same app, but the path into it is more relevant.

That is the useful version of a custom product page.

What a custom product page is

A custom product page, often shortened to CPP, is an additional version of an App Store product page.

Apple currently allows up to 70 custom product pages per app. Each page can have its own:

• screenshots
• app previews
• promotional text
• assigned keywords
• localizations
• unique App Store URL
• optional app deep link

The page needs App Review approval before users can see it. Apple's custom product page documentation is the source of truth for the current features and limits.

A custom page can be reached through:

• its unique URL
• an Apple Ads ad variation
• an assigned App Store keyword after the page is approved, visible, and eligible for search

If none of those routes applies, the user sees the default product page.

Custom product pages are not A/B tests

Custom product pages and Product Page Optimization solve different problems.

Changing a background color on a custom page does not create a clean test. The people reaching that page may already have different intent from people seeing the default page.

If you want to test whether a new screenshot sequence improves the same page for the same traffic, use Product Page Optimization. If you want different traffic to receive a more relevant message, use a custom product page.

Decide whether a use case deserves its own page

Do not start by asking how many pages Apple allows.

Start with three conditions:

1. The intent is distinct. The user is solving a recognizably different problem or comes from a campaign with a specific promise.
2. The page can change meaningfully. You have different benefits, screenshots, proof, or a useful destination inside the app.
3. The page can receive enough traffic to evaluate. There is a keyword group, paid campaign, creator, website, email, or other distribution path.

If only the color changes, the use case probably does not need a page.

If the user need changes but the product does not actually serve it, the page should not exist either. A more specific promise makes an expectation gap worse when the app cannot deliver it.

Good reasons to create a page

• A fitness app serves runners and strength-training users with different features.
• A language app has separate pages for travel phrases and exam preparation.
• A finance app has distinct self-directed investing and retirement-planning workflows.
• A creator campaign promotes one use case that would be buried on the default page.
• An Apple Ads keyword group has clear intent that the default screenshots barely address.

Weak reasons to create a page

• A competitor has many pages, so you want the same count.
• You made a new color treatment without changing the message.
• The page targets a popular term the app does not solve well.
• There is no plan for sending traffic to it.
• The only goal is to repeat the same screenshots in another URL.

Map the audience before designing the page

Write one row for each candidate page:

This table forces the page to continue into the product.

If the first three columns differ but the proof and first action remain exactly the same, the segmentation may be too superficial.

The row also gives you the first measurement plan:

• Did the intended traffic reach the page?
• Did more of those users download?
• Did they complete the first action promised by the page?
• Did they retain or pay at an acceptable rate?

Learn from competitors without copying them

The Appfigures custom product page tutorial uses competitor pages to reveal how established apps segment acquisition. That is useful because a set of pages can show the audiences and use cases a company believes are important enough to support.

Look for:

• the audience named or implied by each page
• which features move into the first screenshots
• whether branding stays consistent across segments
• the Apple Ads terms associated with a page, where observable
• how often the pages are updated
• whether every page leads to the same offer or a different in-app path

Do not assume a competitor's page performs well merely because it exists. You cannot see all of its traffic, budget, conversion, or product data.

Use competitor pages to generate questions:

• Are they separating audiences we currently mix together?
• Does the category use a page for seasonal or local demand?
• Which proof changes when the audience changes?
• Is there a useful niche they ignore?

Then validate those questions with reviews, user interviews, first-party analytics, and your own campaigns.

Plan the first three screenshots

The custom page should feel like the same product with a clearer entrance—not an unrelated app.

Keep the brand, interface, and product truth consistent. Change the order and message around the intended use case.

Give the first three screenshots separate jobs:

1. Name the use case or desired result.
2. Show how the app delivers it.
3. Answer the strongest doubt or show useful proof.

For the budget meal-planning page:

1. Plan a week of affordable dinners
2. Turn the plan into one shopping list
3. Reuse ingredients before they go to waste

For the high-protein page:

1. Build meals around your protein target
2. See macros before saving the plan
3. Repeat a meal-prep week without starting over

The layout can remain consistent. The intent should change.

Use the screenshot guide when the page idea is clear but the first three frames still need a message and sequence.

The Appfigures tutorial suggests a fast first version: if the default page already has separate screenshots for distinct features, reorder the relevant existing frame to the front of a custom page. This can be useful when the asset genuinely answers the new intent. It should not become a permanent substitute for a coherent page designed around the audience.

Create the page in App Store Connect

Apple's current flow is short.

The app must have Ready for Distribution status in at least one country or region before you can create a custom product page.

1. Sign in to App Store Connect.
2. Open Apps and select the app.
3. Select Custom Product Pages in the sidebar.
4. Click Create Custom Product Page or the add button.
5. Enter a reference name you will recognize in Analytics.
6. Start with a blank page or copy an existing product page.
7. Create the page.
8. Add or edit screenshots, previews, promotional text, and eligible keywords.
9. Add localizations where the page and product are ready.
10. Optionally add an app deep link.
11. Save the page and add it for review.
12. Submit it to App Review.

Use a reference name that describes the intent and market, not “Page 3.”

For example:

• budget-meals_us_en
• protein-meal-prep_us_en
• exam-prep_gb_en

The name is internal, but it will matter when several pages appear in Analytics or an API export.

Start blank or copy an existing page?

Copy an existing page when:

• the brand and layout should stay consistent
• most later screenshots remain useful
• only the leading message and a few assets change

Start blank when:

• the use case needs a substantially different sequence
• the default page contains too many irrelevant frames
• the page uses a distinct campaign concept

Copying is faster. It can also preserve weak assumptions. Read the duplicated page again from the perspective of the new user.

Assign keywords for organic search

Apple currently lets you assign eligible keywords from the latest approved app version to a custom product page. When the page is approved, visible, and assigned to a keyword, the custom page can appear instead of the default page for that search.

Apple recommends a unique set of keywords for each page so the most relevant page can appear.

Use the assignment deliberately:

1. Choose a keyword whose intent matches the page.
2. Confirm that the keyword is available to select in App Store Connect.
3. Assign it in every relevant localization.
4. Publish the keyword assignment.
5. Verify visibility after approval and indexing have had time to update.
6. Record the assignment date in the page log.

Apple's current custom product page guide documents the latest-approved-version requirement, per-localization assignment, Publish step, and visibility requirement.

Do not move a term into metadata solely to unlock a custom page. The term still needs to be one of the best uses of limited metadata space.

The Appfigures tutorial suggests using paid campaigns to validate which keyword-page combinations work, then applying that learning to organic assignments. The principle is good: use faster paid feedback to form an organic hypothesis. The paid result still needs enough data, and the user quality should be checked before changing metadata.

Use a custom page in Apple Ads

Apple Ads search-results ad groups can use an ad variation based on an approved custom product page. Apple documents the current ad-variation flow here.

Match one ad-group theme to one page promise.

For example:

Check the ad variation after editing or disabling a page. Apple notes that an ad variation cannot run if its custom product page has been disabled or removed.

Do not build a separate page for every keyword. Group terms that represent the same user intent. “Cheap weekly meals” and “budget dinner planner” may belong to one page. “Keto meal plan” may require another page only if the app truly supports that diet and the message changes meaningfully.

Use the unique URL outside the App Store

Each custom product page has a unique URL.

This makes it useful for:

• creator partnerships
• paid social campaigns
• website landing pages
• newsletters
• QR codes
• product launches
• support or community content aimed at one use case

The external message and App Store page should use the same promise.

If a creator demonstrates fast family dinners, do not send the audience to a generic page led by calorie tracking. The custom URL lets the App Store continue the story instead of restarting it.

Keep a routing table:

This makes broken or outdated links easier to find later.

Add a deep link when the app experience should continue the promise

Apple allows an optional app deep link on a custom product page. On iOS 18 or later, tapping Open can send the user to specific content in the app instead of the default starting screen.

Apple supports universal links or custom URLs and recommends universal links for a more secure, integrated experience. The deep link must be reviewed before it works for users.

Use a deep link when:

• the page promotes a specific feature or collection
• an existing user should return to the relevant place
• the default home screen would make the campaign feel disconnected

Test it before submission. Apple specifically recommends avoiding unnecessary URL shorteners and verifying the URL on a device.

The deep link is part of the custom page metadata and must pass review before it works for users. Apple's configuration guide contains the current platform requirement and test instructions.

Do not deep-link past context a new user needs. The shortest path is not always the clearest path.

Measure more than page conversion

Apple currently shows custom product page data after a page receives at least five first-time downloads.

In App Store Connect Analytics, you can inspect:

• product-page views
• total downloads
• conversion rate
• proceeds
• average proceeds per paying user over available retention milestones
• other downstream metrics supported by the app

You can filter or compare pages by territory, source type, and device. Apple's custom product page analytics guide explains the current dashboard and threshold.

Use a page scorecard:

A higher store conversion rate is not automatically a win.

If a page raises downloads but lowers activation, it may be overpromising or attracting a broader, less suitable user. If conversion is slightly lower but proceeds per user are materially stronger, the page may be doing a better job for the business.

Use the ASO-to-activation guide to define the first useful action and separate first-party product evidence from unsupported page-level attribution.

Keep raw counts next to rates. Five downloads unlock reporting; they do not make the result stable.

Diagnose a weak page

The page gets little traffic

• Verify that it is approved and visible.
• Check the keyword assignment, ad variation, or external URL.
• Confirm that the campaign or source is actually using the custom URL.
• Check the relevant storefront and localization.

The page gets views but few downloads

• Does the first screenshot repeat the traffic source's promise?
• Is the use case real and important enough?
• Do ratings, price, and reviews create a trust gap?
• Does the page show the product rather than only marketing copy?
• Is the page too narrow for the traffic assigned to it?

Downloads improve but activation falls

• Is the page promising a feature that is hard to find after launch?
• Does onboarding continue the same use case?
• Is the deep link appropriate for new users?
• Is the keyword attracting a different user than expected?

Results differ by market

• Compare the page by territory.
• Check whether the screenshots were localized or only translated.
• Revisit local competitors, price expectations, and search language.
• Do not hide the difference inside a global conversion rate.

Keep a page log

Custom product pages become hard to manage when nobody remembers why they were created.

For every page, record:

• reference name
• audience and problem
• assigned keywords
• Apple Ads groups
• external campaigns and URLs
• localizations
• deep link
• approval and publish dates
• first-value event
• current owner
• last review date
• keep, revise, disable, or delete decision

Disabling a page redirects its unique URL to the default page. Deleting a page is permanent and also redirects the old URL. Record the dependent campaigns before either action.

Apple documents both redirect behaviors in the same custom product page configuration guide.

A useful first custom product page

Do not begin with ten pages.

Choose one use case that already has evidence:

• users mention it in reviews
• an Apple Ads keyword group brings relevant traffic
• creators naturally demonstrate it
• the feature has strong activation or revenue
• the default page currently buries it

Write the audience-to-message row. Build the first three screenshots. Create the page, submit it, and attach one understandable traffic source.

Then check the whole path:

Traffic promise → custom page → download → first-value action → retention or revenue

If the message gets clearer at the App Store and disappears after the download, the work is not finished.

Return to the complete App Store ranking guide when the problem is broader than one page or audience.