A sitemap is a list of pages you are asking Google to index. That is the whole contract. Every URL in it should be a page that exists, at that address, and answers when called.
We counted every URL Meetup submits — nearly five million of them — and then started opening them.
Two thirds do not answer. They redirect somewhere else, and the biggest group of them lands somewhere much less specific than the address promised.
Results at a glance
Meetup's two largest sitemap layers are city pages. We opened 15 of them at random and every single one redirected away.
The strategy underneath is sound. The list it hands Google is not.
The layers that redirect
Meetup names fourteen sitemap indexes in its robots file, which makes the shape easy to read.
We sampled five URLs from each layer, spread across each file rather than taken from the top. The city layers redirected 5 out of 5, every time. Groups, find pages and interests redirected 0 out of 5, every time.
A village that becomes a country
The international city layer is the largest single thing in Meetup's sitemap, and it is the one that loses the most.
/cities/gb/s2/derrychorran/book-clubs/ is a hamlet in Northern Ireland crossed with book clubs. It redirects to /find/united-kingdom/.
/cities/ro/cocorastii-misli/language/ is a Romanian commune crossed with language learning. It redirects to /find/romania/.
Whatever village you name and whatever hobby you pick, 1.74 million distinct addresses collapse onto a few hundred country pages. The specificity that made the URL worth generating is gone by the time anybody arrives.
The American layer behaves better. /cities/us/fl/ruskin/events/tech/ redirects to /find/us--fl--ruskin/ — it keeps the town and drops the topic. Still a redirect, but it lands somewhere a person from search would recognise.
What actually answers
The layers that do resolve are the interesting ones, because they show the strategy Meetup was reaching for.
A place crossed with an interest is a genuinely good page to own. It is true this year and next, and whatever is happening locally simply flows through it. Nothing on it expires, which is the hard problem every events business has.
Meetup clearly understands that. It has 829,486 topic pages and 193,286 group pages that resolve exactly where they should.
The container beats the event
Underneath the place pages sit the groups, and a group is the other thing that does not expire.
Only 172,332 of Meetup's URLs are events, about 3.5% of the total. Everything else is a container that events pass through.
That is the right instinct, and it is the opposite of what most listings sites do. They build a page per event, watch each one rank for a week and die, and end up with an index full of things that already happened.
It works anyway, and that
It works anyway, which is the trap
rsquo;s the trap
None of this has visibly hurt Meetup. Domain rank 96, and our Website Audit scored the homepage 83 out of 100.
Which is exactly why it is worth writing about. A site strong enough can carry three million redirecting URLs in its sitemap for years and nothing obvious breaks. The cost is invisible: crawl budget spent re-discovering that a URL moved, and a set of very specific addresses that no longer answer specifically.
If you have Meetup's authority, this is survivable. If you do not, it is the sort of thing that quietly stops a new section from ever getting indexed.
Copy this in an afternoon
Two lessons here and they point in opposite directions, which is the useful part.
1. Take the strategy. Find the noun in your business that never expires — the place, the topic, the venue, the organiser — and make that the page. Let the dated items live inside it.
2. Do not take the execution. Fetch a random sample of your own sitemap and follow the redirects. It takes ten minutes and it is the single cheapest audit you can run.
3. Only submit URLs that answer. If a URL redirects, put its destination in the sitemap instead. A redirecting entry is a request for Google to do work and then throw the result away.
4. Do not generate an address more specific than your content. Meetup's international city URLs promise a village and a hobby and deliver a country. Generating a URL you cannot actually serve is where this whole technique turns against you.
What you cannot copy
Twenty years of people linking to their own group. Meetup's 335,989 referring domains came from organisers putting their group's URL on their own sites, year after year. That reservoir is what makes the redirect problem survivable. A newer site making the same mistake would simply not get indexed, and would never learn why.
And here is what we could not check:
Redirect behaviour is sampled, not exhaustive. We tested 5 URLs from each of 8 layers, 40 in total, spread through each file rather than taken from the top. The city layers were unanimous, which is strong evidence but not a census. We did not fetch 3.2 million URLs to prove it.
Declared pages are not indexed pages. It is entirely possible Google worked this out years ago and quietly stopped crawling the city layer, in which case the cost is already paid and invisible from outside.
We did not measure its AI visibility. Our checker has been unreliable behind its bot challenge this week, and a number from a run that did not finish is worse than none.
No traffic or revenue data. None was available and none is claimed.
Before you audit anything else, find out whether the URLs you submit actually answer. Our Website Audit runs a real crawler over your page and reports redirects, dead links and the technical faults that quietly waste crawl budget — the same check that scored Meetup 83 out of 100.
- A real crawler, not a guess from an index
- Redirect chains, dead outbound links and hreflang faults flagged in plain words
- Free, no signup, results in about 30 seconds
Frequently asked questions
How many URLs does Meetup submit?
4,868,827 across fourteen sitemap indexes, counted on 25 August 2026 by fetching every leaf rather than sampling. The largest layers are international city URLs at 1,741,277, USA city URLs at 1,488,706 and localised topic pages at 829,486. Groups account for 193,286 and events for 172,332.
How do you know two thirds redirect?
We sampled 5 URLs from each of 8 layers, taken from spread positions within each file rather than the top. All 5 international city URLs, all 5 USA city URLs and all 5 from the separate cities index redirected. Groups, find pages and interests redirected none. Those three city layers total 3,241,995 URLs, or 66.6% of everything submitted. The sample was unanimous, but it is a sample.
Where do the city URLs go?
International ones collapse to a country page: /cities/gb/s2/derrychorran/book-clubs/ becomes /find/united-kingdom/, and /cities/ro/cocorastii-misli/language/ becomes /find/romania/. American ones keep the town but drop the topic: /cities/us/fl/ruskin/events/tech/ becomes /find/us--fl--ruskin/.
Is putting redirects in a sitemap actually harmful?
It is against the guidance rather than catastrophic. A sitemap is meant to list canonical, indexable URLs; a redirecting entry asks a crawler to fetch a page, discover it moved, and fetch again. At a few hundred URLs nobody notices. At 3.2 million it is a meaningful share of the crawl budget spent learning nothing, and the specific addresses never accumulate any value of their own.
What is its backlink profile?
Our Backlink Analyzer returned Domain Rank 96 out of 100, 335,989 referring domains, 171,267 referring IPs and 96,858 referring subnets, from a total link count in the tens of millions. That works out at roughly one referring domain for every fourteen URLs submitted.
What did the website audit find?
83 out of 100, with 1 critical issue, 2 warnings and 7 notices against 111 checks passed. On-page SEO 23 of 25, technical SEO 63 of 67, speed 24 of 29, mobile 2 of 2. The critical issue was language links missing return links. Among the warnings was more than one H1 heading, which on a templated site appears on every page of that type. The title tag is 59 characters and the meta description 152.
How does this compare with Eventbrite?
We measured both on the same day. Eventbrite returned Domain Rank 98 and 2,451,399 referring domains, roughly seven times Meetup's, because promoting a ticketed event means linking to the ticket page. Eventbrite's sitemap problem is different in kind: its URLs resolve, but 83% of its sitemap files are filtered browse pages, including time filters whose meaning changes daily.
What should I do with pages for events that have passed?
Keep them reachable for anyone holding an old link, remove them from your sitemap, and point your internal links and structured data at the permanent container instead. Deleting them creates broken links; leaving them in your index slowly fills your search results with things nobody can attend.
The idea at the centre of Meetup's architecture is the best answer we have seen to the expiring-inventory problem: rank the container, not the thing inside it.
It just also happens to be a demonstration that a good strategy and a correct implementation are different achievements, and that a strong enough domain will hide the gap between them for a very long time.
Run a free audit on your own site, then take twenty URLs out of your sitemap and see where they actually land.
Measured on 25 August 2026. URL counts come from meetup.com's own sitemap files; every leaf of all fourteen indexes was fetched and counted rather than sampled. Redirect behaviour was sampled at 5 URLs per layer across 8 layers, not exhaustively. Declared URLs are not indexed pages.
Link and audit figures are free runs of our own tools, and the Eventbrite comparison used the same tool on the same day. No traffic or revenue data was available to us and none is claimed here.