How to construct your own Find A Grave search query URLs


By Chris Mills


This article was first posted on 9 Nov 2014, I sent a link to it out to some of the mailing lists I maintain, and less than 24 hours later I have a number of comments and corrections, so I am already updating the article.

Searching for people on Find A Grave is a fairly straightforward process, although there are some things that I have found frustrating about the searches. There are several things I have found no solution to, so I'll list them off and get them out of the way first:

Can't search for someone by their nickname.
A search for a first name won't also search the middle name field.
If you run a search and include cemeteries in a particular county, when you hit the back arrow on your browser to rerun the search, it loses the county criteria and you have to select a different state and then reselect the original state to be able to select a county again (very annoying).
When you search within a cemetery, there is no way to turn off searching for maiden names, which you don't want to do sometimes. However, you can control that when you are searching from a people search screen (by default in a people search screen it does not search for maiden names).

There is one more thing that I found truly annoying but I have just found a solution to it, and the solution actually unlocks other interesting possibilities, which I hope to explore further.

I do a great deal of work on Forest Lawn Glendale, which now has over 300,000 Find A Grave memorials within it. Sometimes searching on a common surname within Forest Lawn is quite agonizing. For example, searching on the name "Smith" within Forest Lawn Glendale (which I will henceforth abbreviate as FLG) returned 3,587 matches when I searched on the surname within the cemetery. That is of course one of the extreme examples since Smith is such a common name, but the point is that searching for any reasonably common surname can cause some challenges when searching within a cemetery that size.

Because of the research I am doing I frequently search for someone with a particular name and a death year to narrow the results of the search. You can run that search down to the county level within the search screen in Find A Grave, but there is no documented way to run that search only within a particular cemetery.

Having played around with Find A Grave quite a bit over the years, I had some theories about things that might be able to help me run a search like that within a specific cemetery, even if they weren't documented. I started out by taking a look at the URL that is displayed when you run a people search in Find A Grave. Let's use as our example searching for anyone named John Smith who died in 1985 and is buried in Los Angeles County, California. Here is the URL that is generated when I run that search:

http://www.findagrave.com/cgi-bin/fg.cgi?page=gsr&GSfn=john&GSmn=&GSln=smith&GSbyrel=all&GSby=&GSdyrel=in&GSdy=1985&GScntry=4&GSst=6&GScnty=201&GSgrid=&df=all&GSob=n

Now, that URL looks like quite a mouthful, but what's really cool about it is that when I run a search using those criteria, it knocked the search list down to just five names, which is a pretty manageable list of results. However, let's look into dissecting this URL and see what each piece does.

http://www.findagrave.com/cgi-bin/fg.cgi?page=gsr

I believe every Find A Grave people search begins with this string. If that is the case, we can ignore it and move on to the parts that actually do something specific.

&GSfn=john

This is the part that inserts the first name into the query. Apparently GSfn= means the text that immediately follows is the first name you are looking for.

&GSmn=

This is the middle name. I left it blank, so rather than being followed by a name it immediately goes to the next part of the query, which is fair enough.

&GSln=smith

This is the last name. So GSln= is what represents the prefix to the last name you are searching for.

&GSbyrel=all&GSby=&GSdyrel=in&GSdy=1985

I'm pretty sure the "byrel" and "dyrel" pertain to the birth and death year options to search before or after a year (rather than an exact year). I don't normally use those options so I've tended to ignore them. What I do understand clearly from this part of the URL is that GSby= precedes an exact birth year and GSdy= precedes an exact death year search. Since all I searched for here was the death year, the only part that is filled out is the GSdy=1985.

&GScntry=4&GSst=6&GScnty=201&

These are the geographical constraints on the cemetery location. Because of what I punched in on the search we can deduce that GScntry stands for the country the cemetery is located in, GSst stands for the state, and GScnty stands for the county. In addition, we can derive the internal Find A Grave index values from this for the USA, which is 4, the state of California, which is 6, and Los Angeles County, which is 201. I have added those to my Forest Lawn database just on general principle, and as time goes by I suspect I will accumulate other geographical index values used by Find A Grave and add those to my database as well.

GSgrid=&df=all&GSob=n

This is the last part of the URL. In all honesty, I have no idea what it does. But that doesn't matter. I gleaned plenty of information about how the search is constructed from the other parts which I did understand.

Once I parsed out the different parts of the search, I started playing around with some names I had a list of which I wanted to search on. The problem with doing a search like the one demonstrated above is that it may not seem like it takes that much time to set it up, but it does take a minimum of several seconds just to type in or copy and paste names into the name fields, then add any years you want, then choose the right values from the country, state and county pull down menus if so desired. All those seconds add up over time.

So while I was playing around with this I pulled up a list of names I was searching on in a spreadsheet and added columns which contained the different components of the Find A Grave query URL, then wrote a formula to concatenate the names and query components into one cell. Once I was finished I copied and pasted the results of the formula (using the "paste special" command in excel to paste the results, not the underlying formula) into another column. I then took those cells and copied and pasted them into the URL line of my browser. Voila! Each URL I copied into the browser functioned exactly as if I had manually run each search in Find A Grave. So that turned out to be quite a time saver.

Now, returning to my gripe above about not being able to run this search within a specific cemetery (a search by names and dates, not just names). I went back to a specific cemetery and did a name search within that cemetery to see how the search URL constrained the results to within a specific cemetery. I used FLG as that is one of my favorite cemeteries and I have the Find A Grave cemetery ID for it memorized.

http://www.findagrave.com/cgi-bin/fg.cgi?page=gsr&GSiman=1&GScid=7974&GSfn=john&GSln=smith

If you look at the resulting URL carefully you should be able to recognize some of the parts we described above. What is interesting here is that just preceding the part of the query that specifies the first name, there is the following text:

&GScid=7974 (I had erroneously listed this as "CScid", thanks to Jon Reeves for catching that)

I know that the Find A Grave ID for Forest Lawn Glendale is 7974. Therefore the verbiage that precedes it, "GScid" must stand for the cemetery id field, which constrains the search results to that cemetery.

As a test, I now combined the two different search URLs into one, guessing that as long as the cemetery id field preceded the names that it should work. I did, however, have to change the death year as there were apparently no John Smiths who died in 1985 in FLG.

Bingo! I got three matches for John Smith who all died in 1942 and are buried in Forest Lawn Glendale. My next step was to then remove the other geographical constraints from the query, as there was no need to specify Los Angeles County since I was telling it the specific cemetery. As I anticipated, that search also worked fine. The URL is displayed below:

http://www.findagrave.com/cgi-bin/fg.cgi?page=gsr&GScid=7974&GSfn=john&GSmn=&GSln=smith&GSbyrel=all&GSby=&GSdyrel=in&GSdy=1942&GSgrid=&df=all&GSob=n

(When first published the query line had a place in it with two consecutive ampersands, another catch by Jon Reeves. That didn't seem to break the query, but one of the ampersands was extraneous and did nothing).

Now that I had puzzled the search out to this level, I added the icing on the cake. Yes, it was not terribly difficult to copy the URLs from excel and then paste them into my browser to run the search, but I wanted to speed things up even more. So I created an HTML file with all the names I wanted to search on. The HTML is pretty simple, you just add the <a href= preceding the URL, then follow with a > and then add what you want the link to display as and then close the tag with a </a>. I had each link display with the first and last name I was searching on and the death year. Using that file I have plowed through almost a thousand names on my search list in just a few days, which I can tell you for sure is much faster searching than what I was doing before.

I haven't bothered putting that HTML file online as I don't have anyone else working on that file right now, but it works fine locally on my system. I just click the link, get whatever information I need from the Find A Grave memorials that come up on the list, then click the back arrow on my browser to return to my list of names, go to the next name on the list, and click that link. And so forth and so on, not ad infinitum, at least, but as long as I am going through that list, which could be a while as there are still 11,000 more names to go through (You can probably see why I am trying to speed this up as much as possible!).

If I play around with this more I may either add to this article or write a sequel to it. There are not a whole lot of people on Find A Grave who are going to be interested in tweaking their searches to this level, but if I help even a few other people it will be worthwhile.

10 Nov 2014

Clay was kind enough to send me a link to a page on Mike Maxton's site where Mike has documented a list of the field names used by Find A Grave. He identifies the queries as PHP queries, which is plausible, although I don't know enough about PHP to say that is true. Here's a link to Mike's page:

Find A Grave database field names

I'm going to include Mike's text verbatim below (virtually everything below this point will be from Mike's page, I am only putting quote marks around the first paragraph as putting them in additional places may lead to confusion and people trying to put them into query lines, which is not appropriate). He doesn't have a copyright notice posted so I believe he is just putting the information out there for everyone to use, another kind soul who is "paying it forward", I guess. Jon Reeves had figured out some of this stuff from sheer mental acuity and noted it in an email to me. I am presenting Mike's text without comment but will probably keep updating this page over time as more comments come in or as I play around with some of the other field names in queries.

"I'm sure there are more. Here are the Find A Grave database field names used in PHP queries, via the URL."
(updated Sep 12 2014)

page=gsr (grave search results)
page = gr (grave record)
page = dr (delete record. Must have privilege)
page = csr (cemetery search record)
page = cr ( cemetery record)
page = mr (member record)
page=pi (photo information?)
page=pv (photo value)
page=ps (photo sort) Must have privilege.
page=abr (add burial record)
page=dfl (digital flowers)
page=ss (success stories)
page=listFAQS (list Frequently Asked Questions / Guidelines /Rules)
page=memberSearch (find a contributor's profile page)
page=rapList (request a photo List)
page=listEdits (member's list of edits, pending, approved, declined)

-------------------------------------------------------------------------------------------------------------------
GRAVE SEARCH
GSfn = grave search first name
GSmn = grave search middle name
GSln = grave search last name

GSbyrel = all, in, before, after
grave search birth year relative to
GSby = grave search birth year
GSdyrel = all, in, before, after
grave search death year relative to
GSdy = grave search death year
GScntry =0 = grave search country
0 = all
GSst = 0 = grave search state
0 = all

GSob = grave search order by
c = cemetery
n = name
d = death
b = birth
t = date added to FAG, newest first (t = time?)

GScid = grave search cemetery identification

GSiman = grave search include maiden name
0 = don't include maiden name
1 = include maident name

GSpartial = Grave Search partial last name
0 = don't include partial last name search
1 = include partial last name search

df = date filter
np = no photo
p = photo
1 = 1 day
7 = 7 days
30 = 30 days
90 = 90 days

GSsr = search results
1 = show memorials 1 - 40
41 = show memorials 41 - 80
81 = show memorials 81 - 120
121 = show memorials 121 - 160
You can put in any number up to the max number of records returned in the query.
etc.

GSmid= 47363392 = member identification (all records MANAGED by that person)
GSmcid=47363392 = member identification (all records CREATED by that person)
both turn on partial last name search by default.
GSmpid=47363392 = member photo identification (all records where that person placed a photo on the memorial (partial last name search doesn't work here)

pt = cemetery name, in text (pt = place text ?) spaces must be shown as %20

If you search for a LastName = 123 (or any 2 or more numbers), you get all records with a blank last name.

If you search for a LastName = 123 (or any 2 or more numbers), with the partial last name block checked, you get all (?) records. Add a FirstName, for instance, George, and it returns all records that have a first name of George!

&MRid=47363392
*******************************************************************************************************************
REQUEST A PHOTO PAGE (page=rapList)

page=rapList (request a photo List)

rapMode=contributor

rapContributorId=47363392

orderBy=status
= name
=cemetery

obad=desc (order by ascending/descending. This variable is used with OrderBy value.)
=asc

(End of text quoted verbatim from Mike Maxton's page)

As I mentioned above, as I play around with this stuff or get comments from other people about it I will continue adding to this page. I am impressed that I got so many comments in such a short period of time, I thought this would be so arcane that almost no one would be interested in it, but apparently that is not the case.

Page first created 9 November 2014

Return to Genealogy Links
Return to Main Page

Contact us

© 2014 by Chris Mills (portions by Mike Maxton quoted ARE NOT copyrighted by Chris Mills)