In short: A hosted site generates pages nobody wrote. Member profiles, forum threads, blog tags, store filters and app screens all produce URLs, and most carry no answer to anything.
They are not harmful because they exist. They become harmful when one of them is the page a category question retrieves instead of the page you wrote.
Wix's own documentation flags one case directly: public member pages such as Followers and Profile need a noindex set by hand, because nothing does it for you.
Count Them Before Judging Them
Open your sitemap and read it. Not the page count in the dashboard, which counts the pages you made: the sitemap, which counts what exists.
The gap between the two is the part of your site you did not write. On a site with an app installed it is routinely the larger number, and almost nobody has looked at it.
Sort what you find into three: pages that answer something, pages that are navigation, and pages that are somebody's profile. Only the first should be in the sitemap.
The Member Pages
Where a site has accounts, the platform generates a public page per member and per view of that member. Wix names Followers and Profile as cases that stay indexable unless you set a noindex yourself.
Two reasons to deal with this, and the second is the one people miss. They are thin pages competing with your real ones. And they are other people's names on pages you publish, which is a privacy question before it is a retrieval one.
App Pages And Filter URLs
The same test from the store and collection modules applies unchanged: is there a sentence worth writing at the top of this page.
A forum thread often passes, because a real question with a real answer under it is exactly what these systems draw on. A tag archive with three posts usually fails. A filtered product view fails unless the filter matches how buyers actually ask, in which case it deserves a written introduction and becomes a page properly.
The failure this prevents: a category question retrieves your tag archive, which is a heading and a list of titles, instead of the page where you answered the question. Both are yours, and the wrong one was easier for the system to reach. That is not a content problem, it is an inventory problem.
What To Do With Each Group
Pages that answer something. Leave them in and treat them like any other page: answer first, source and date attached.
Navigation. Keep it usable for people and out of the sitemap. Nothing is lost, because nobody was going to cite a filter.
Profiles and account pages. Noindex them deliberately, and check the result rather than the setting.
Then fetch the sitemap again and confirm what it now lists. A settings screen says what should happen and the sitemap says what did.
The Ones Worth Keeping Deliberately
It is worth saying that this is not a cull.
Community content is the material these systems draw on most readily, precisely because it is not written by the seller. A forum where real questions get real answers is an asset, and pruning it to tidy a sitemap would be the wrong reading of this lesson. The target is pages with nothing on them, not pages you did not write.
Do this once, then at handover. Generated pages appear when an app is installed and nowhere else, so this is not a monthly chore. It is worth an hour when something new goes on the site, and worth an hour when somebody new inherits it.
Key Takeaways
- A hosted site generates pages nobody wrote, and the sitemap rather than the dashboard is where you find out how many.
- Public member pages such as profiles and follower lists stay indexable unless you set a noindex by hand.
- Sort generated pages into answers, navigation and profiles, and keep only the first group in the sitemap.
- The failure to prevent is a thin generated page being retrieved instead of the page where you answered the question.
- Community content is not the target. A forum where real questions get real answers is exactly what these systems draw on.
Check yourself
Before you move on
Not scored, not recorded, and not part of the certificate. Both answers are settled by a sentence in this lesson, and the reasoning appears whichever option you pick.
- 01
Where do you find out how many pages your site actually has?
- 02
Which generated pages are worth keeping in the sitemap?