As far as the church name or location in the title attribute, Google will let you go up to 70 characters before it cuts off the title when displaying results. It looks like some of the pages have room to add that information at the end, which could help users searching for you and will have some SEO benefit, but won’t hurt the bookmarkers since the front of the title is untouched.
http://www.google.com/search?q=site:fumcbirmingham.org

—– start quote

In the eight years of its existence, our website has grown to roughly 1,500 web pages, including nearly 700 sermons in our archives. These pages would require more than 6 reams of paper to print.

Use of the website has also grown dramatically. We average more than 130,000 hits each month – more than 1.5 million hits each year. Each month we have more than 4,000 different visitors. About 12% of the people who visit our site come back 10 or more times during the month.

Most of the visitors are from North America, but we have also had visitors from South America, Western Europe, Eastern Europe, Australia, Asia, the Caribbean, Middle East, Sub-Saharan Africa, and Pacific islands.

—– end quote

Interesting point about assuring your bio pages come up #1. I’d never considered that issue of controlling what people read first. I wanted to try someone other than Gladstone. We don’t have seem to have a staff member with a really common last name long enough to abbreviate. Googling “Rev. Jeff Nelson” with or without the quotes make our bio page #1, but it’s named nelson.htm so it doesn’t tell us much. I tried Googling “Mary Feldmaier” without the quotes and I was amazed when her bio page (mfeldmai.htm) came up as Google’s #1. “Beverly Richardson” without the quotes gave her bio page (rchrdsn.htm – I don’t make up these names!) as #4. I suspect that having lots of hits is worth more than having a search keyword in the file name when Google does its ranking, but I don’t really know. I guess no one knows since Google tries to keep the algorithm secret to avoid scams.

My comment about the “sitemap” should have said “search”. The PERL search I wrote worked just fine on a straight HTML website, including letting you choose files and folders to include or ignore. I’m curious about why having a database-driven website would help with the search.

Having a database-driven website would have some definite advantages. We will probably be experimenting with it for a small subdomain we want to redesign. But so far we’ve muddled along without problems just having each folder “owned” by one staff member and asking them only to work within a folder they “own.” It’s just a discipline the staff follows, nothing we use technology to enforce. I keep expecting problems, but we’ve never had one.

About the closing B and FONT tags… Yes, it’s true they are right there after the title. But that same sequence occurs elsewhere in the page where you wouldn’t want to replace it with a closing H1 tag. We might be able to use Dreamweaver or some other software which allows wildcard search/replace, but I’m doubtful it would work terribly well. For one thing, over the years the HTML has drifted away from the clean HTML o the page you happened to look at. I know that we even have some pages where the closing B and FONT tags occur in the middle of the title and then another opening set of B and FONT tags appear immediately after them. For 1500 pages, it’s daunting to think how many different combos there might be.

On the principal that “when life gives you lemons, make lemonade,” here’s an advantage to using that old-fashioned FONT tag. It assures that all browsers will treat changing the displayed text size properly. On one of the websites I recently did, we used CSS and had a dickens of a time getting IE to reliably change the text size. Most ways of defining the font size in a CSS don’t work when you try to change the text size in IE. I certainly wouldn’t suggest people continue to use FONT just for that reason, but it is nice that folks can reliably expand the font on all our web pages.

Fun talking with you about this, Mickey! Thanks again!!

Mary

Replacing the [font] and [b] tags for [H1] look pretty simple. I’m looking at the code on your “Contact Us” page right now and it looks like this:

[FONT face="Arial, Helvetica, sans-serif" color=#003466 size=5][B]Contact Us[/B][/FONT]

The closing [B] and [font] tags are right there. Is it not that way on all of the other pages?

You are correct, though, that being in a smaller town makes it somewhat less important to rank well since you already come up first for most searches. Your only consideration is the much larger town in Alabama that probably comes up first for phrases like “Birmingham church”.

You said — “…having the name of the church and the city be the bulk of the text used for the link to the page would be pretty irritating.” — That’s a good point. I had forgotten about how that would show up in your internal searches that you power with Google. I still would suggest your church name first (maybe just “First UMC”), if for no other reason than bookmarks. The title of the page is the default text of a bookmark, and “worship” is a pretty useless name for a bookmark.

Carl Gladstone ranks well, but it’s a bad example. It’s a somewhat less common name, especially if you add his middle name or “methodist” to the query. How about Jeff Nelson or Carl Price? While it’s not critical to have everyone ranked high, it can help. Google our pastor – Randy Mickler. He’s made headlines in the past for some of his views. While our church supports those views (and likely most other Christians do as well), the media has been rather harsh. Read any of the links that come up after his bio on our site and you’ll see what I mean. No matter what kind of information is out there about one of your staff members, it’s nice to be able to control what people read at the top spot.

I don’t recall saying you needed a DB-driven site to do your own sitemap.

One of the nice aspects of a DB-driven site is that you can allow other staff members to work on their area of the site, but you can limit how much damage they can do. As the site (and church) grows, this will become a more likely scenario. I agree that it would be a massive undertaking. Our site has about 2200 pages in Google (more or less on the site, depending on how you count individual pages) and it took a few months.

Mary

I can imagine replacing all the <font…><b&gt stuff with <h1>, but how we would find the corresponding </b>&lt/font> and replace that with </h1> I can’t imagine.

A few comments on your comments …

The weird Firefox formatting thing happened recently when we pulled the site out of frames. It’s due to an unneeded column in a table in the SSI files, so it will be easy to fix. Our webmaster just hasn’t gotten around to it yet.

I’d love to see photos of people from our church on every page in place of the stained glass, flowers, cartoons, commercial photos, etc. What a wonderful feel that would give the website. But daunting to consider for even a small fraction of the pages on our huge site.

I agree about clutter of the youth pages. It’s grown by accretion over the years. Our whole youth ministry usage of the Internet is under review right now, so there may be a major redesign soon. I hope so. We are now using Google groups, Google calendars, Flickr, and YouTube in the youth ministry, so it’s not clear how much will be left in the youth section of our website. Part of the clutter on the current youth page is 3 lines of calendars for middle school and 3 lines for high school. That will soon be reduced to one line when our transition from monthly printed calendars to Google calendars is complete, so that will help a bit.

I like the idea of labeling all the PDF files. Adobe is so slow to start on my computer that I myself am always irritated when I discover I just clicked on a PDF file without knowing it.

I also like the idea of linking names to bio pages and adding phone number and email addresses to bio pages. That could greatly reduce the number of places we put a phone number, since it would only need to be on the bio page (and likely the Contact Us page as well).

[As an aside, my favorite church bio pages are on Hyde Park UMC in Tampa. Great format. Here’s the senior pastor’s page: http://www.hydeparkumc.org/default.aspx?id=83.

‘De-bordering’ the photos and table on the Contact Us page would be a nice improvement.

Your comments under Search Engine Optimization are interesting. I’m not sure that I agree about putting our church name and city in the TITLE tag for every page. I don’t think doing that would make all that much difference in our search engine placement since that info does occur on every page in the boilerplate at the bottom. I know the TITLE tag usually gets a bit more credit from the search engine than does text in the body of the page, but anyone looking for ‘xxx methodist birmingham michigan’ is likely to get our site. Since we have well over 1M hits a year, our pages tend to rank well with Google, et al. Perhaps your suggestion would be more important for a small church with fewer hits to raise the rank of their pages? For searches of just our own site, having the name of the church and the city be the bulk of the text used for the link to the page would be pretty irritating. What do you think?

Your comment about our not using CSS is well taken. I certainly use CSS on all the new websites I work on and also in revisions of websites which aren’t too huge. Our not using it on this website is a historical problem. When we designed our site nearly 7 years ago, CSS wasn’t widely supported. (Did it even exist back then?) So now we have 1500+ pages with specific formatting built in. Sigh… Although there is a .css file given in the HEAD for each page, it was just added when we pulled the pages out of frames and I don’t think we actually use it at all. Converting to CSS sounds pretty overwhelming to me. If you have a suggestion on how to do that, I’d love to hear it. I can imagine replacing all the stuff with but how we would find the corresponding and replace that with I can’t imagine.

The short page names are also an artifact of our history. 7 years ago meeting the 8.3 naming convention mattered and we made it a website standard. I recently ran across some public standard which still recommends that, although quite frankly I can’t imagine why. I would guess that for many small church websites including keywords in the file name matters to raise the rank in the search engine. Fortunately, as I mentioned, we get enough hits that our abbreviated names don’t seem to hurt us with search engines. For instance, if you Google ‘carl thomas gladstone’ (one of our pastors), the first website you get is his music website and the second one is his bio page on our church website. If you Google ‘carl gladstone methodist’ you get some other person for the #1 hit and then Carl’s bio page on our website as the #2 hit. So I think we are OK with these abbreviated names, but many churches would not be.

Our church definitely is a very active one. When I was the church webmaster, I used to joke with our pastor about how much easier my job would be if only we didn’t do so darned much stuff! It’s also a very warm and welcoming church which has been growing at a slow but steady pace over the past decade. It really feels like ‘home’!

You suggestion of making the cross and flame in the nav area a link to the home page is a good one. We want to do all we can to help our readers!

About our search engine. We used to have a full-text search engine which I wrote years ago in PERL. It was great when we had 300 pages. When we got to 1000 pages, it took several minutes to search the site. So we switched to Google. It is certainly unfortunate that using Google means you don’t get your most recent pages. I’d like to try the Google Sitemap functionality, which allows the webmaster to tell Google about new pages which should be indexed so they appear in the search results immediately. I’m hoping that that will help us overcome the problem with Google not finding new pages quickly. But I don’t think there is any way to get info about what people are searching for, and I agree with you that it is a real shame to lose that.

I’m curious about why you say you need to have a database-driven website to do your own sitemap. The one I wrote worked fine on our HTML pages, including having the ability to include or exclude certain files and folders from the search.

You are right that it’s pretty hard to imagine converting our 1500 page website to a database-driven site! I have had long conversations about this with a friend who manages the content management systems for a Fortune 500 company. Every time we discuss it, we conclude that the benefits of converting would not begin to justify the cost.

Thanks again for your thoughts about our website, Mickey. You are performing a wonderful service for folks by doing this! I’ll be interested to see whether you think some of your suggestions apply differently to small sites with few hits vs. larger sites with more hits.

Mary