As many of you know, I’m working on a new version of InspectorSeek.com and I want some input. I’m trying to group our members in metro areas (on certain pages—not search results) for SEO reasons, and I’m writing a simple script that takes raw metro data and converts it into a human-readable string. Can you guys take a quick look at this list and tell me if anything looks amiss?
Please note that certain areas will show under multiple states if they’re on a border. Also note that some smaller areas won’t necessarily be represented by this list—I’m working with metropolitan areas right now.
List clearly flawed. Will repost when I sort out the details.
Dale,
lol, no but dang near. He missed the parts where all the smart people live. Down on the south end is where the folks live who can’t punch a pin through a ballot card properly. (Wait for the fur to fly on this one).
Good for the central part of Western Washington only. Bellingham in the northwest, Vancouver in the southwest, Spokane in the east, and Pasco / Tri-Cities in the southeast.
Some of what you are showing at least around Pensacola are neighborhoods not actual towns (Brent and Ferry Pass) and missing is other real towns around Pensacola. Not trying to pee on your parade but your initial request for input was probably the way to go because you will get real information from the folks who live there. May take a little longer but will be more accurate in the long run.
Search engines are very particular about how they handle links. If you have more than 50-75 links on a given page it’s going to harder to convince a search engine spider to follow the links lower down on that page. Thus, splitting our membership up by State and then Metro will lead to a search engine friendly hierarchy. If we just split by zip code there would be thousands of links per state. By using metro areas, we’ll have a little over 50 links on the front page (US States and Canadian Provinces), and then under 50 links on the next page (links to each metropolitan area), and finally links to each member on the 3rd page. This keeps the hierarchy under 4 levels deep (good) and keeps the links per page under 75 (also good).
In the end, it won’t matter for anyone who’s searching on the site, because if someone searches for 19147 it will skip all that and take them to the page for Philadelphia, PA. It’s mostly for search engine listing.
They’re not supposed to be towns—I’m trying to break the country up into major metropolitan areas. So neighborhoods are good.
Right now I’m trying to find a way to automate the process so that as groupings change and zip codes come and go we can just download new raw data and recreate the grouping database. If it looks like that won’t work, then we might have to rely on a more hands-on approach. We’ll see…
Just an idea. I would post this message over at scriptlance.com! I’m sure your aware but if not a host of international datebase coders exist on that site and I’m sure someone has a idea on how to do what your looking for.
There are a few major ways to group locations. The most recent is the Core Based Statistical Area (CBSA) method. It’s based both on how different areas share a statistical core in terms of population, and also in terms of interaction. For example, people who live in the “Philadelphia, Camden and Wilmington” CBSA are more likely to a) live near each other and b) interact with each other. There’s no reason to re-invent the wheel here—many very talented statisticians worked hard to make CBSA data as accurate as possible, and I doubt anything we could contract would be nearly as accurate.
My main concern here is to make sure we represent this statistical data as accurately and user-friendly as possible (“Philadelphia, Camden and Wilmington” is definitely easier for an end-user to deal with than “Philadelphia-Camden-Wilmington, PA-NJ-DE-MD”). We’ll probably then build in a way to tweak the system based on user input.
Down on the south end is where the folks live who can’t punch a pin through a ballot card properly. (Wait for the fur to fly on this one).