XML Sitemap for a Fan Site and What to Leave Out of It

A fan wiki I helped clean up last spring had 4,200 URLs in its XML sitemap. Search Console reported 1,100 of them as indexed. The rest were tag archives, image attachment pages, old redirects and printer-friendly duplicates that the sitemap plugin had added without anyone asking. The site owner thought the sitemap was helping. It was mostly telling search engines to waste time.

An XML sitemap for a fan site is simple in theory: a list of the pages you want found. In practice, gaming communities produce a lot of thin and duplicate pages, and most sitemap tools include everything by default. This guide covers what belongs in the file, what to cut, how to split it as the site grows and how to read the reports that tell you whether it works.

What an XML Sitemap Actually Does

A sitemap is a hint, not a command. It tells crawlers which URLs exist and, through the lastmod date, which ones changed recently. It does not force indexing, it does not improve rankings on its own and it does not replace internal links. A page that appears in the sitemap but has no links pointing to it from the rest of the site will often be crawled and then ignored.

Where sitemaps earn their keep is on large or fast-changing sites. A wiki with 3,000 character pages, or a news section that publishes patch coverage within an hour of release, benefits because crawlers find new and updated pages faster. A ten page clan site gets almost nothing from one, though it costs nothing either.

What Belongs in a Fan Site Sitemap

The rule I use is blunt: only list a URL if you would be happy to see it as a search result. For most gaming communities that means:

Guide pages, character or item pages, and walkthrough chapters with real content.
Category hubs that have their own introduction and are not just an auto-generated list.
News and patch note posts that are still accurate or clearly dated.
The homepage and a small number of evergreen pages such as a beginner's guide.

Every URL in the file should return a 200 status, be the canonical version of itself and be allowed by robots.txt. If any of those three fail, the URL is noise.

What to Cut Before Search Engines See It

This is where most fan sites lose crawl attention. Common offenders, roughly in order of how often I find them:

URL type	Why it hurts	Fix
Tag archives	Hundreds of near-identical lists	Exclude from sitemap, consider noindex
Media attachment pages	One thin page per screenshot	Redirect to the parent post
Redirected URLs	Crawler follows a hop for nothing	List the final URL only
Paginated archives	Page 14 of a category is rarely useful	Keep page one, drop the rest
Member profiles	Often empty and thin	Exclude unless profiles hold real content

After one cleanup like this, the wiki above went from 4,200 listed URLs to about 1,350. Indexed pages rose slightly over the following two months, because crawlers stopped spending visits on junk and reached updated guides sooner.

Why "Submit Every Page" Is Bad Advice

Many tutorials still tell site owners to make sure every single URL is in the sitemap, as if completeness were the goal. For a gaming community it usually is not. Search engines read a sitemap partly as a signal of what you think matters. When half the file is attachment pages and tag lists, that signal becomes meaningless, and the coverage report fills with "Crawled, currently not indexed" entries that you then waste evenings worrying about.

A short, clean sitemap that matches your real content is more useful than a complete one. If you are unsure about a page type, leave it out for a month and watch whether anything changes. Usually nothing does.

Splitting the Sitemap as the Site Grows

The protocol allows 50,000 URLs or 50 MB uncompressed per file. Few fan sites hit that, but splitting early still helps, because separate files give separate reports. A practical structure:

A sitemap index file that lists the others.
One file for guides and wiki pages.
One file for news and patch posts.
One file for category hubs.

When the guides file shows 95% indexed and the news file shows 40%, you know exactly where to look. A single combined file hides that difference. If you rename or merge pages often, check the guide on renaming a wiki page without losing traffic, since old URLs lingering in the sitemap are a frequent cause of redirect warnings.

Getting lastmod Right

The lastmod field should change only when the main content of a page changes. Many setups update it whenever anything on the page moves, such as a new comment, a sidebar widget or a footer year. When every page claims to have changed today, crawlers learn to ignore the field entirely.

For a wiki, tie lastmod to real edits of the article body. For patch coverage, update it when you add new numbers or correct old ones, not when someone fixes a typo in the comments. It is a small detail that keeps your genuinely updated pages near the front of the crawl queue.

Reading the Reports

Submit the sitemap index once in Search Console and in Bing Webmaster Tools, and reference it in robots.txt with a Sitemap line. Then check monthly, not daily. Three numbers matter: how many URLs were discovered, how many are indexed, and which errors appear. A sudden jump in "Not found" usually means deleted pages are still listed. A steady rise in "Duplicate without user-selected canonical" points to parameters or print views slipping in.

Sitemap errors often travel with linking problems. If the report shows pages discovered but rarely crawled, look at how they are linked internally, because broken internal links on long-running wikis tend to isolate exactly the pages the sitemap is trying to promote.

FAQ

Does a small clan site need an XML sitemap?

Not really. If the site has fewer than about 50 pages and they all link to each other, crawlers will find everything without help. Adding one is harmless, so keep it if your platform generates it automatically.

Should images have their own sitemap?

Only if image search brings you meaningful traffic, for example a site full of map screenshots or card art. Otherwise, images inside indexed pages are found through the pages themselves.

How often should I resubmit my sitemap?

Almost never. Once submitted, search engines fetch it on their own schedule. Resubmit only after a large structural change, such as moving the wiki to a new URL pattern.

The Practical Takeaway

Open your sitemap today and count the URL types in it. Remove anything you would not want as a search result, split the rest into a few logical files and make sure lastmod only moves when content does. Then leave it alone and check the reports once a month. More site housekeeping guides are in our web tips section.