pages_read_user_content App Review Rejection: Expert Diagnosis

A denied pages_read_user_content app review usually means Meta could not verify that your app reads user-generated content on Pages the user manages — posts, comments, and ratings from users or other Pages — the way the official Permissions Reference describes. This is not Page Public Content Access, and it is not the same as reading content the Page itself published. This guide grounds diagnosis in Meta’s Permissions Reference (updated Sep 29, 2026): exact allowed usage, official dependency, screencast bar, adjacent-permission confusion, 7-day cooldown risk, and when a specialist audit helps.

What this permission is (official framing)

Meta states that pages_read_user_content allows your app to read user-generated content on the Page — such as posts, comments, and ratings by users or other Pages — and to delete user comments on Page posts. Official allowed usage is to read user’s and other Page’s content posted on the Page if you need it to help manage the Page.

Official allowed usage bullets from the Permissions Reference:

• Get user generated content on your Page.
• Get posts that your Page is tagged in.
• Delete comments posted by users on your Page.

Official dependency: pages_show_list. In product terms, Advanced Access here is trust to surface UGC for Pages the app user owns or manages — not a license to crawl public Pages your customer does not administer.

Allowed usage + what Meta wants in App Review

Keep notes inside Meta’s allowed usage: help manage the Page by reading UGC and, where your product actually does it, deleting user comments. Meta asks for specific examples of why your app needs to read user-generated content on behalf of your app users for the pages they own.

Official screencast requirements from the Permissions Reference:

• Demonstrate the complete Facebook Login process on your app platform, showing how your app user grants your app this permission.
• Demonstrate how your app user reads a user-generated comment on their Facebook Page on your app platform.
• Showcase that the user-generated comment is successfully displayed on your app platform.

That bar is narrow on purpose. A calendar of Page posts you authored, an insights chart, or a Messenger inbox demo does not prove UGC read recreateability — even if those features are excellent for other permissions.

Why Meta rejects pages_read_user_content

• Page-authored content mistaken for UGC — screencast shows posts published by the Page (pages_read_engagement territory) while never opening a visitor comment, visitor post, rating, or tagged-in post.
• Confused with Page Public Content Access — team argues “we need public Page data” while requesting owned-Page UGC permission (or the reverse). PPCA is a separate feature for Pages you do not manage.
• Moderation story without display proof — use case claims comment moderation, but the app never shows a user comment rendered in-product.
• Delete-comment claim without read path — notes mention deleting comments while the video never loads UGC first.
• Empty Test User Page — Login succeeds, but the Page has no visitor comments for the reviewer to see.

Generic banners (unable to verify permissions, inadequate demonstration) often wrap this same recreateability failure. Cross-read Unable to Verify Permissions when the email is nonspecific.

What reviewers look for (psychology)

Reviewers need to believe a stranger following your recording can grant the permission and see someone else’s comment (or equivalent UGC) appear in your UI. They will not invent visitor comments mid-review. They also punish category confusion: reading Page-owned posts, reading public Pages you do not manage, and reading UGC on managed Pages are three different trust stories.

Official dependency: pages_show_list

Meta lists pages_show_list as the dependency. That permission lets your app show and verify Pages a person manages. If Page selection never appears, or the reviewer cannot attach a manageable Page, UGC read proof collapses even when your essay is policy-correct. Bundle honesty matters: request pages_show_list because your connect flow lists Pages — not as filler.

pages_read_user_content vs adjacent permissions

pages_read_engagement covers content posted by the Page, follower metadata, and Page insights-style reads — different from visitor UGC. pages_manage_engagement is about creating, editing, and deleting comments as management actions (and depends on pages_read_user_content plus pages_show_list). Page Public Content Access is for public data on Pages where you lack owned-Page engagement/UGC permissions. Mixing those labels in one use case makes every sentence look unfocused.

SaaS stacks that publish and moderate (for example MagicAI Social Media Suite listing pages_read_user_content beside pages_manage_posts) still need a UGC-specific demo beat — publish proof alone does not clear this permission.

Common demo gaps

• Screencast of native Facebook comments while your app UI never mirrors that comment.
• Instructions that assume the reviewer already seeded visitor comments you never prepared.
• Use case that only says “we manage Pages” without naming UGC surfaces (comments, visitor posts, ratings, tagged posts).
• Demo that works only on a production Page with no Test User path.
• Notes that paste PPCA or engagement essays under the pages_read_user_content form field.

These are diagnosis categories, not a portable approval script. Page shapes differ; specialists map whether the failure is wrong permission family, missing UGC seed data, or display path gaps — then rebuild one coherent package.

Also see: a related case study where ads_read was approved after every other Page and Ads permission already passed.

When a specialist audit helps

Bring a specialist when you cannot tell whether Meta denied UGC recreateability, engagement-permission confusion, or a PPCA story filed under the wrong form; when Test Pages have no visitor comments; or when publishing SaaS demos keep getting mistaken for UGC proof. The audit separates those tracks and identifies what a cold reviewer still cannot recreate — without a fake universal “delete comment” click path that ignores your product.