Before we run the audit, we need to make sure we're asking the right questions about the right competitors to the right buyers. This document presents what we've learned about Pursue ATL's market — your job is to tell us what we got right, what we got wrong, and what we missed.
Before we measure how often AI assistants name Pursue ATL when an Atlanta builder asks where to plug into the scene, these three signals tell us whether AI crawlers can even reach and trust the site. They're derived directly from the Layer 1 technical scan — no interpretation, just the baseline.
Atlanta builders increasingly start their search for "where do I plug in" not on Google but inside an AI assistant — asking ChatGPT or Claude which community, calendar, or room is worth their time. A private member community that sits on top of Atlanta's incubators and aggregates the city's events for founders, students, and operators lives or dies by being the answer to that question. The companies and communities that establish AI visibility now lock in a compounding advantage: early citations teach the platforms which domains to trust, and that trust reinforces itself before the rest of the local ecosystem realizes the scoreboard changed.
This Foundation Review is the input we validate together before the audit runs. It lays out three things: the competitive landscape — the other places an Atlanta builder could go — which shapes how we construct head-to-head queries; the buyer personas, which determine the search intent patterns we test; and the technical baseline, which determines whether AI platforms can access Pursue ATL's content at all. Each section is here so you can confirm what we got right and correct what we didn't, because the query set the audit fires is only as good as these inputs.
The validation call is a working session with real stakes. Your answers decide which inputs drive the buyer query set across the AI platforms we test. Two kinds of decisions come out of it: input validation — are the right competitors in the right tiers, are the inferred personas real, are the feature strengths honest — and engineering triage — which technical fixes can start before results even come back. The Pre-Call Checklist at the end aggregates every one of those decisions into a single page so you can prepare without re-reading anything.
Purpose This is the validation step before we run a generative-engine optimization (GEO) audit for Pursue ATL. We've assembled a model of your market as an Atlanta builder community — competitors, personas, capabilities, and buyer pain points — plus a technical scan of your site. Everything here is a draft for you to confirm or correct, not a finished verdict.
Your Job Read each section and react. Where we got a competitor tier, a persona role, or a feature strength wrong, tell us — those corrections directly reshape the query set the audit fires. The purple boxes throughout are the specific questions we most need your judgment on.
Confidence Badges Each item carries a confidence badge. High means we observed it directly on your site. Medium means we inferred it from context and want your confirmation. Treat every medium-confidence item as a question, not a claim.
→ Your category spans five distinct audiences — pre-seed founders, Georgia Tech students, still-employed career-switchers, founding engineers, and ecosystem program managers. Is your actual applicant pool concentrated in one or two of these, or genuinely all five? If it's concentrated, we cluster the query set tightly around those segments; if it's truly broad, we spread queries across five intent patterns and the audit gets meaningfully wider.
5 personas: 3 decision-makers, 2 influencers. These are the people whose "where do I plug in?" search the audit has to mirror — they drive every query we fire.
Critical Review Area Personas are the highest-leverage input in this document. If a persona is wrong — wrong role, wrong influence, or not actually in your applicant pool — every query built from it is wasted. Scrutinize these harder than anything else here.
Data Sourcing Note Names, roles, seniority, and technical level come straight from your site and onboarding flow (high confidence) or from category inference where the site didn't show us (medium confidence). The buying jobs and query focus areas rows are synthesized — our read of how each persona would actually search. Those are exactly what we want you to confirm.
→ Does a pre-seed founder judge Pursue ATL by what's in the room (members, events, office hours) or by outcomes (co-founders found, funding reached)? If it's outcomes, we shift toward outcome-style queries — and the weak/absent features below suddenly matter to the audit.
→ Do GT students search for an Atlanta-wide community at all, or default to on-campus options like CREATE-X and Startup Exchange first? If they search campus-first, student-targeted queries need campus-qualified phrasing or they'll never surface Pursue ATL.
→ Daniel is inferred, not observed. Do still-employed career-switchers actually apply to Pursue ATL, or do they lurk in the newsletter and never join? If they don't convert to members, we drop the aspiring-founder query cluster entirely.
→ Priya is also inferred. Does a founding engineer go searching for a community, or do they arrive because their company is already plugged in? If operators come via their startup rather than a search, their queries don't belong in the set — a different question than Daniel's "do they join at all," but the same risk of building a cluster nobody searches.
→ Jordan represents the supply side — someone reaching builders, not seeking community. Is this audience numerous enough in your world to warrant its own query cluster, or is it a handful of partners better handled outside the audit? If it's just a few relationships, we collapse this persona and reallocate those queries to the demand-side founders.
Missing Personas? A few roles sometimes show up in Atlanta builder-community deals — do they show up in yours? Bootcamp grad / self-taught dev breaking in (a distinct on-ramp from CS students, searching very differently); local angel or scout (joins to source deals, not to build); corporate innovation / venture-studio scout (plugs in to spot talent and startups). Each would warrant its own query cluster. Who else shows up in your applicant pool that we haven't named?
3 primary + 4 secondary competitors. Tier assignments decide which match-ups the audit tests head-to-head versus as general category awareness.
Why Tiers Matter Primary tier means we build direct match-up queries — "best community for Atlanta founders," "Atlanta founder Discord vs Slack," "where do Atlanta startup events get listed" — roughly 6–8 per primary competitor, so these three tiers drive on the order of 18–24 head-to-head queries. Secondary competitors appear only in broader category-awareness queries. Note that Atlanta Tech Village and ATDC have been removed from the competitive set: you partner with these incubators and the site brings awareness to their programming rather than competing with them, so head-to-head "Pursue ATL vs ATV/ATDC" comparisons would misrepresent the relationship. We're least certain about TECH404 / Startup 404 Slack (medium confidence): it's your closest format competitor as an always-on local chat, but its current activity level is unverified. If TECH404 is now a ghost town and rarely the real alternative a builder weighs, moving it to secondary would shift roughly 6–8 queries out of the head-to-head set.
→ Three things to react to: (1) Who's missing? Local players like Goodie Nation, Switchyards, Founder Institute Atlanta, or Russell Innovation Center could belong here. (2) Is TECH404 still primary? If its Slack has gone quiet, it drops to secondary and ~6–8 head-to-head queries move with it. (3) Is anyone irrelevant? Indie Hackers is national and topic-organized — if no Atlanta builder actually weighs it against you, we cut it so it doesn't dilute the competitive set.
12 buyer-level capabilities mapped. These determine which capability queries the audit tests — what a builder would search for when comparing where to plug in.
A vetted room of real builders, not a public free-for-all — every member is hand-reviewed so the people I meet are actually serious.
One place to see every founder meetup, pitch night, and workshop in Atlanta instead of digging through scattered Eventbrites.
A standing time each week to show what I'm building and get real feedback from other builders.
An active chat where I can ask questions, share wins, and get answers fast — not a ghost-town Slack nobody posts in.
A community that's actually about my city — local people I can meet in person, not a global forum where nobody is near me.
A place where student founders from any Atlanta campus are welcome and treated as real builders, not just observers.
A short weekly digest of what matters — local jobs, events, and updates — so I don't have to follow ten feeds to stay current.
I can plug into the scene without paying for a coworking desk or membership I can't afford yet.
Help me actually find a co-founder or early teammate, not just chat with people building their own things.
Real mentors, curriculum, or a cohort that walks me from idea to launch — not just open networking.
Get me in front of investors or funding — warm intros, demo days, or seed money to actually start.
A dedicated space I can show up to and work from, run into people, and feel part of something physical.
Prioritization Question Six capabilities are rated Strong: Curated Application-Only Membership, Centralized Atlanta Tech Event Calendar, Weekly Live Office Hours & Feedback, Atlanta-Specific Geographic Focus, Student & Campus Inclusion, and Free to Join. The audit tests all 12, but competitive-differentiation queries will emphasize 3. Which of these best represents where Pursue ATL actually wins a builder's choice over an open Slack or a coworking membership?
→ Three calibration questions: (1) Is Discord really "moderate"? A builder choosing between you and TECH404's Slack is comparing chat vitality directly — if your Discord is your strongest retention driver, that rating undersells you and changes which capability queries we lead with. (2) Are the weak/absent four truly absent? If any informal co-founder matching or mentorship happens, those queries re-enter the set. (3) Merge candidates? "Event Calendar" and "Newsletter & Ecosystem Intel" are both ecosystem-intel — should they be tested as one capability or two?
10 pain points: 4 high, 6 medium severity. The buyer language here is how queries get phrased — these are the frustrations a builder types into an AI assistant.
→ React on three fronts: (1) Severity. Is "can't find a co-founder" really as urgent as "the scene is scattered," given your weak co-founder-matching capability — or is it aspirational rather than something you solve today? (2) Buyer language. Do these phrasings sound like your actual applicants, or are the inferred ones off? (3) Missing pains we'd probe in your category: fear of posting unfinished work in a vetted room, imposter syndrome among non-technical founders, and event burnout / FOMO from too many things to attend. Do any of those resonate more than what's listed?
A Layer 1 scan of the technical foundation — whether AI crawlers can reach, render, and trust pursueatl.com. These are engineering hand-offs, not content recommendations; the full audit handles content once we have query-response data.
Engineering — Start Immediately One finding is a hard blocker: robots.txt explicitly blocks the AI crawlers (GPTBot, ClaudeBot, Google-Extended, Bytespider) that build the indexes behind ChatGPT, Claude, and Gemini answers. This almost certainly comes from Cloudflare's default "Block AI bots" rule rather than a deliberate choice — and it makes a community whose value is being "the room you're pointed to" invisible to the assistants builders ask. Engineering should also verify whether the /events calendar is server-side rendered; if it's client-side only, fixing robots.txt won't help because the freshest asset still renders as an empty shell. Both can start today, before the validation call.
What we found: The Cloudflare-managed robots.txt at pursueatl.com explicitly Disallows GPTBot (OpenAI/ChatGPT), ClaudeBot (Anthropic/Claude), Google-Extended (Google Gemini), and Bytespider (ByteDance), plus Amazonbot, Applebot-Extended, CCBot, and meta-externalagent. A Content-Signal directive on the wildcard agent also sets ai-train=no. PerplexityBot, ChatGPT-User (live browse), and Googlebot remain allowed via the final wildcard "User-Agent: * / Allow: /" block. The block list matches Cloudflare's default "Block AI bots" managed rule verbatim.
Why it matters: These are the exact crawlers that build the retrieval indexes behind AI answers. Blocking GPTBot and ClaudeBot prevents ChatGPT and Claude from ingesting pursueatl.com for grounding; blocking Google-Extended removes the site from Gemini's training/grounding corpus. For a community whose entire value proposition is being "the single room" a builder is pointed to, being invisible to the AI assistants those builders increasingly ask ("what's the best community for Atlanta founders?", "where do Atlanta startup events get listed?") is directly self-defeating. This is almost certainly an unintended consequence of leaving Cloudflare's managed AI-bot block enabled (Cloudflare flipped this default to block AI crawlers in July 2025) rather than a deliberate editorial choice.
Recommended fix: In the Cloudflare dashboard, disable the managed "Block AI Scrapers and Crawlers" / AI Crawl Control rule (or publish an overriding robots.txt) so GPTBot, ClaudeBot, Google-Extended, and PerplexityBot are allowed. At minimum set Content-Signal to permit search and ai-input; decide ai-train per business preference. Re-fetch /robots.txt to confirm, then request re-crawl in Google Search Console and via IndexNow.
What we found: sitemap.xml contains no <lastmod> elements (only priority and changefreq). 13 of 14 inventoried pages expose no visible publish/updated date; only /events surfaces a relative "updated 1 day ago" stamp. Last-Modified header data was not available through our rendered-markdown method.
Why it matters: AI answer engines weight recency heavily. ChatGPT concentrates citations on recently updated content (ConvertMate found 76.4% of ChatGPT's most-cited pages were updated within the last 30 days; Ahrefs found AI-cited pages average 25.7% fresher than non-cited). Without <lastmod> or a visible date, crawlers cannot establish recency and pages forfeit freshness credit — even the event calendar, which is genuinely refreshed weekly, cannot prove it.
Recommended fix: Populate <lastmod> in sitemap.xml from the build/CMS, surface a visible "Last updated" date on the calendar and organization pages, and ensure Last-Modified HTTP headers are emitted. Since the calendar auto-refreshes weekly, expose that timestamp on every event page.
What we found: The 10 organization event pages (content depth ~0.30–0.35) each consist of roughly one 20-word description of the organization followed by a templated chronological list of event entries. There is little self-contained prose beyond the single org blurb.
Why it matters: LLMs cite self-contained passages that answer a question. A one-sentence blurb plus an event list gives an AI almost nothing to quote when asked, e.g., "what does ATDC offer Atlanta founders?" These pages also dilute the site's overall content-depth signal. (Prioritization of this work against net-new opportunities is handled downstream once query-loss data exists.)
Recommended fix: Expand each organization page with a few substantive paragraphs — what the organization is, who it serves, its signature programs, and how it fits the Atlanta ecosystem — so each page stands alone as a citable answer rather than a bare event feed.
The following items could not be assessed through our analysis method (rendered markdown). We recommend your engineering team verify these manually before the validation call.
What to check: The /events calendar and the 10 /events/organizations/* pages are dynamic, application-driven listings (178 aggregated events, automated weekly refresh). Our method reads rendered markdown and cannot confirm whether event titles, dates, and organization descriptions are present in the initial server-rendered HTML or injected client-side via JavaScript.
Recommended action: Load /events and a sample organization page with JavaScript disabled (or use view-source / Screaming Frog in text-only mode) and confirm event entries appear in the raw HTML. If they are client-side rendered, add SSR or prerendering for the calendar and organization pages — otherwise non-rendering AI crawlers see an empty shell even after the robots.txt fix.
What to check: JSON-LD structured data is not visible in rendered markdown, so we could not confirm whether Organization, Event, or ItemList schema is present on the calendar and event pages.
Recommended action: Validate with the Google Rich Results Test and a Schema.org validator. Add Event + ItemList schema to the calendar and organization pages and Organization schema sitewide — schema.org/Event markup is directly consumed by search and AI event surfacing, and your 178-event calendar is your strongest asset to expose.
What to check: Meta descriptions and Open Graph tags are not present in rendered markdown and could not be assessed through our method.
Recommended action: Check via view-source or a social-preview tool and ensure every page has a unique meta description and complete OG tags (title, description, image, url) — these shape search snippets and the context an AI shows alongside a cited link.
Partial Sample Two metrics rest on almost no data: freshness could be scored on only 1 of 14 pages (12 product pages and the sitemap expose no date at all), and schema coverage couldn't be assessed on any page. Read the freshness 1.0 as "one page happens to be current," not "the site is fresh." The verification items above are the way to close these blind spots — verify them manually before the call.
Why Now GEO visibility is a timing advantage, and the window is open:
• AI search adoption is accelerating — how builders discover communities and events is shifting quarter over quarter, away from Google and toward assistants.
• Early citations compound: domains AI platforms learn to trust now get cited more often as that trust reinforces itself.
• Whoever in the Atlanta scene establishes AI visibility first creates a structural disadvantage for everyone who moves later.
• The Atlanta builder-community space is still early-innings in GEO — acting now means competing against inaction, not against entrenched strategies.
The full audit measures how often AI assistants name Pursue ATL across the real queries Atlanta builders ask — "best community for Atlanta founders," "where Atlanta startup events get listed," "Atlanta founder Discord vs Slack," "how to break into Atlanta tech." You'll see exactly which of those return TECH404, Georgia Tech Startup Exchange, or Startup Atlanta but not Pursue ATL — and what it would take to appear in them. Because fixing the robots.txt block and confirming the calendar renders server-side raises your baseline before we even measure, the engineering work you start now makes the first read stronger.
A 45–60 minute working session to walk through this document — confirm competitors, personas, features, and pain points, and resolve the open decisions in the checklist below.
We build the buyer query set from the validated inputs and run it across the selected AI platforms, capturing who gets cited for each query.
Visibility analysis, competitive positioning, and a prioritized three-layer action plan — including the content recommendations that this Foundation Review deliberately holds back until we know which gaps cost you citations.
Start Now — Engineering Three technical fixes don't depend on the rest of the audit and will improve your baseline visibility before we even measure it: (1) disable Cloudflare's managed AI-bot block in robots.txt so GPTBot, ClaudeBot, Google-Extended, and PerplexityBot are allowed, then re-fetch /robots.txt to confirm; (2) load /events with JavaScript disabled to confirm the 178-event calendar is in the server-rendered HTML, and add SSR/prerendering if it isn't; (3) populate sitemap <lastmod> and surface visible "Last updated" dates so the weekly calendar can prove its freshness. The robots.txt change is the one to verify first — if crawlers stay blocked, it supersedes everything else.
Two jobs before we meet. The questions on the left require your judgment — no one knows your community better than you. The engineering tasks on the right don't require the call at all.