I still remember the Tuesday afternoon I opened Search Console for a Brooklyn dental client and saw the "Discovered – currently not indexed" count sitting at 1,847 URLs. Not a hack. Not a penalty. Just years of location pages in Astoria, Flatbush, and Park Slope quietly cannibalizing each other until Google threw up its hands. That's the thing about doing SEO in New York: the technical problems are the same ones you'd find in Des Moines, but the stakes are brutal. You're not competing with the bakery three blocks away anymore. You're competing with Zocdoc, with national chains that have entire engineering teams, with aggregators that scrape your service pages and outrank you for your own business name.
I've run technical audits on roughly 40 NYC businesses over the past five years — dentists, contractors, a couple of law firms, one very confused restaurant group that had accidentally created 12 separate websites for 12 separate locations. This is the checklist I actually use, in the order I actually run it, plus the New York-specific stuff nobody puts in their generic PDF.
Key Takeaways
- Crawl and indexation come first — everything else is noise until Google can actually see your pages
- NYC businesses face a unique problem: borough-level and neighborhood-level pages that compete with each other
- NAP consistency across hundreds of local directories is a genuine technical task in a city this dense
- Core Web Vitals thresholds: LCP under 2.5s, INP under 200ms, CLS under 0.1 — mobile first, always
- Schema markup (LocalBusiness, Service, FAQ) is now a prerequisite for showing up in AI-generated answers
- Audit quarterly. New York SERPs shift fast, and a competitor can outrank you in weeks
The technical SEO audit checklist NYC businesses actually need
Most checklists floating around are written for a national e-commerce site and then retrofitted to local. That's backwards. A Manhattan deli has almost nothing in common with an online retailer except the mechanics of crawling. So let me start with what's genuinely different about doing this work in the five boroughs.
Why the New York context changes your priorities
In most markets, you're optimizing one website for one audience. In NYC, you're often optimizing one business for an audience that's fragmented by neighborhood, and each fragment behaves differently. Someone searching "emergency plumber Upper East Side" at 2am on their phone has different intent than someone in Staten Island comparing quotes next Sunday morning.
The trap I see constantly: a business creates a page for every neighborhood they serve, all with near-identical content. I audited a moving company in 2023 that had 89 location pages. Eighty-six of them were duplicates with the neighborhood name swapped in. Google indexed three. The rest sat in limbo, and worse, they were dragging down the authority of the pages that did work.
Real talk: if your location pages differ only by a city name and a stock image, they aren't helping. They're a liability.
Step 1 — crawl and indexation (do this before anything else)
Nothing downstream matters if Google can't find or index your pages. Here's what I check, in order:
- Robots.txt — fetch it directly. I've found three NYC sites in the last year with a staging robots.txt still live, blocking the entire site. One of them had been blocked for 11 months without anyone noticing.
- XML sitemap — is it present, accurate, and submitted? Does it only contain canonical, indexable, 200-status URLs? A sitemap full of redirects and 404s is worse than no sitemap.
- Search Console coverage report — sort by "Excluded" and understand why each bucket is excluded. "Discovered, not indexed" is a crawl-budget or quality signal. "Crawled, not indexed" usually means thin content.
- Canonical tags — self-referencing on every page, and consistent. I once found a dental site where the homepage canonical pointed to a URL with a trailing slash that 404'd.
- Status codes — run a full crawl and export every 4xx, 5xx, and redirect chain. Aim for zero chains longer than one hop.
I use Screaming Frog for this, but the free version caps at 500 URLs. For a multi-location NYC business with neighborhood pages, that's not enough — budget for the paid version or use Sitebulb.
Step 2 — site architecture and internal linking
Here's where local NYC sites fall apart most often. You've got a flat structure where every service page and every location page sits one click from the homepage. Sounds fine, until you realize you've got 140 pages competing for the same crawl budget and none of them are strongly linked to each other.
The structure I recommend, and the one that actually worked for a Queens HVAC client who went from position 14 to position 3 for "AC repair Queens" in about four months:
| Level | Page type | Links to |
|---|---|---|
| 1 | Homepage | Borough hubs, top services |
| 2 | Borough hub (Brooklyn, Queens, etc.) | Neighborhood pages, all services |
| 3 | Neighborhood page (Park Slope, Astoria) | Relevant services, sibling neighborhoods |
| 3 | Service page | Related services, service-area hubs |
Notice the cross-linking between neighborhood pages and service pages. That's what most sites miss. Your Astoria page should link to your plumbing service page, and your plumbing page should link back to the borough hubs where you actually operate.
Step 3 — Core Web Vitals, mobile first
New York is a mobile-first city in a way that's hard to overstate. People search on the subway, on the sidewalk, waiting for the L train. Your desktop performance numbers are almost irrelevant.
The thresholds Google publishes haven't changed: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. I'll be honest — most local business sites I audit fail at least one of these on mobile, usually LCP, because someone installed a chat widget, a popup, and four tracking scripts without thinking about it.
Quick wins that actually move the needle:
- Compress and properly size hero images — WebP format, and serve the right dimensions for mobile
- Defer non-critical JavaScript. That chat widget doesn't need to load in the first second
- Use a CDN. Even a cheap one. Your server in a single US data center is adding latency you don't need
- Audit your third-party scripts quarterly. Most sites accumulate them like barnacles
Step 4 — schema markup and local signals
Schema is no longer optional if you want to show up in AI-generated answers from ChatGPT, Perplexity, or Google's AI Overviews. These systems lean heavily on structured data to figure out what a business actually is and where it operates.
At minimum, implement:
- LocalBusiness schema with correct address, phone, geo-coordinates, and opening hours — for every physical location
- Service schema on service pages, with areaServed defined at the neighborhood level where it applies
- FAQPage schema on pages with genuinely useful Q&A (not manufactured ones)
- BreadcrumbList for architecture clarity
Test everything with Google's Rich Results Test. I've lost count of how many sites have schema with a typo that silently invalidates the whole block.
Step 5 — NAP consistency across hundreds of listings
This one is genuinely a New York problem more than anywhere else. A business with four locations in Manhattan, Brooklyn, Queens, and the Bronx has to maintain consistent Name, Address, Phone data across Google Business Profile, Apple Maps, Bing Places, Yelp, and dozens of industry-specific directories. When I audited a multi-location veterinary practice last year, I found 47 separate directory listings with three different phone numbers and two outdated addresses.
The fix isn't glamorous: pick one canonical format for each field and enforce it everywhere. Use a tool like BrightLocal or Yext if you can afford it. If you can't, build a spreadsheet and work through it in batches. It's tedious. It works.
Step 6 — redirects, 404s, and the graveyard of old campaigns
Every NYC business I've audited has a graveyard — old landing pages from past campaigns, discontinued services, abandoned microsites. Those pages accumulate 404s, and those 404s leak authority if they're linked from anywhere still live.
Crawl the site, export every 404, and decide: redirect to the closest equivalent page, or return a proper 410 if the page genuinely shouldn't exist. Don't blanket-redirect everything to the homepage. That's a signal Google reads as low quality.
What tools and templates should you actually use?
You'll find a thousand "SEO audit checklist PDF" downloads online. Most are recycled from 2019 and missing INP (which replaced FID in March 2024) entirely. Here's what I actually use:
| Task | Tool | Cost |
|---|---|---|
| Full-site crawl | Screaming Frog (paid) or Sitebulb | $259/year or $13/month |
| Indexation monitoring | Google Search Console | Free |
| Core Web Vitals field data | PageSpeed Insights + CrUX | Free |
| Schema validation | Rich Results Test, Schema.org validator | Free |
| Local listing management | BrightLocal | ~$39/month |
| Rank tracking (local grid) | Local Falcon | ~$25/month |
For a spreadsheet-based version, you can build it in Google Sheets in about an hour: one tab per audit section, a status column (pass/fail/needs work), and a priority column (high/medium/low). I've shared that template with clients and it's honestly more useful than most paid tools because it forces you to think about priorities instead of just generating reports.
How often should a New York business run this audit?
Full technical audit twice a year. Quick crawl-and-monitor pass monthly. That's my honest answer, and it comes from a mistake I made early on — I audited a client's site thoroughly in January, declared victory, and didn't touch it again until June. By then, a competitor had outranked them for their main term because a plugin update had added 12 seconds to mobile load time. Nobody noticed.
New York SERPs move faster than almost anywhere. If you're in a competitive vertical — legal, dental, home services — assume your rankings are a moving target and check the basics every four weeks.
What most technical SEO checklists get wrong for NYC businesses
They treat your site in isolation. But in a city this dense, your technical problems are often competitive problems. That aggregator outranking you? They're not beating you on page speed. They're beating you because they have 40,000 pages of indexed content and you have 40.
They also ignore the multi-location reality. Most checklists assume one address. If you've got four, every item on this list gets multiplied — four sets of schema, four sets of NAP data, four times the internal linking complexity.
And they almost universally skip AI search visibility. Whether you like it or not, a growing share of "near me" queries are being answered by AI systems that pull from structured data and cited sources. If your schema is broken and your content is thin, you're invisible to that layer entirely.
So — run the crawl. Fix the indexation. Get the schema right. And then do it again in four months, because in this city, standing still is the same as falling behind.
The businesses winning in New York right now aren't the ones with the prettiest websites. They're the ones whose technical foundation nobody has to think about, because it just works. That's a boring answer, and after five years of doing this, boring is exactly what I'd bet on.
