Overview
The Publish Section contains properties that apply to sites that are published on the web. Several of the properties apply to most published sites. The remaining properties apply to Family History Hosting customers only.
All Sites
Base URL
Two features in GedSite require the Base URL of your site when it is published, Add Canonical Links and Create SiteMap. GedSite uses the Base URL property to create URLs for pages in your site after the site has been published.
GedSite appends the subfolder and filename of each page to the Base URL to form the URL for the published page.
| Example 1: Your site is published to "example.com" | |
|---|---|
| Set Base URL to: | https://www.example.com |
| A page filename is: | search.htm |
| The resulting URL is: | https://www.example.com/up/search.htm |
| Example 2: Your site is published to "example.com/genealogy" | |
| Set Base URL to: | https://www.example.com/genealogy |
| A page filename is: | search.htm |
| The resulting URL is: | https://www.example.com/genealogy/up/search.htm |
In both examples above, the Base URL uses the https: protocol. If your domain does not support HTTPS, use the http: protocol.
Add Canonical Links
If you publish a site online, and the site is not private, you may want to add a canonical link element to your pages, especially if there is more than one network path to your content. The canonical link element specifies the canonical ("preferred") URL for a page.
To add a canonical link element to your pages, enter the base URL for the site in the Base URL property and set Add Canonical Links to checked. GedSite will set the canonical URL for the page by adding an HTML LINK element to the head of each page that indicates the preferred URL for the page.
You must specify a Base URL or the Add Canonical Links property will be disabled. Canonical URLs include the absolute URL for a page, and GedSite uses the Base URL to create the absolute URL.
Adding a canonical link element will not directly affect the visible content of any pages or the operation of the site, but will influence how some search engines index the pages of the site.
See the Base URL property description to understand how GedSite appends the subfolder and filename of each page to the Base URL to form the canonical URL for the page.
Technical Details
The primary reason to add canonical link elements is to instruct search engines which version of a URL is the preferred version when a single page is accessible via two (or more) URLs.
There are several reasons why a single page might be available via multiple URLs. As an example, here are several ways to see the homepage for Bezansons.com:
https://www.bezansons.comhttps://www.bezansons.com/index.htmhttp://www.bezansons.comhttp://www.bezansons.com/index.htmhttps://bezansons.comhttps://bezansons.com/index.htmhttp://bezansons.comhttp://bezansons.com/index.htm
In the list above, the URLs are all aliases; there is a single document, but the web server recognizes multiple URLs to request it.
If the "index.htm" page for Bezansons.com specifies a canonical URL, Google (and other search engines) will consider all the URLs above as references to the same document. When other sites link to any of the URLs that lead to the document, those links will be counted towards the canonical URL, and that improves the placement of the document in search results. When the document appears in search results, Google will use the canonical URL.
Other Examples
In addition to the URL aliases shown above, there are other reasons why the same document might appear via different URLs. It is beyond the scope of this help page to describe those reasons. Adding a canonical link element should be useful in most, if not all, examples where a site's content is available via different URLs. However, it is up to the user to ensure that the canonical URL will actually lead to the same document.. If you publish the same content on two different servers, but you allow the two versions to get out of sync, the canonical URL will not be correct and may lead to confusing search results.
Create SiteMap
When Create SiteMap is checked, GedSite creates a sitemap.xml file in the Output (-o) folder. The sitemap.xml file conforms to the version 0.9 schema from sitemaps.org which is supported by Google and other search engines.
The sitemap.xml file will include entries for all the HTML pages (.HTM, .HTML) under the Output (-o) folder.
You must specify a Base URL or the Create Sitemap property will be disabled. Entries in the sitemap.xml file include the full URL for a file, and the Base URL is the base URL for those entries.
You must inform search engines of the existence of the sitemap.xml file; some search engines may automatically detect it, but most will not. For example, to inform Google of a sitemap, use the Sitemaps tab in the Google Search Console.
Use Shared Libraries
The Use Shared Libraries checkbox determines whether the generated site will use shared JavaScript libraries in place of libraries stored in the Output (-o) folder.
If Use Shared Libraries is checked, the generated site will use JavaScript libraries that are stored on a high-speed, high-availability content distribution network provided by Google for frequently used JavaScript libraries such as the jQuery library used by GedSite. Using shared libraries will reduce the load on the server where you host your site and will help your pages load as quickly as possible.
If you do not have an active Internet connection when browsing a local copy of your site on your own PC, you should uncheck the Use Shared Libraries checkbox. However, when you build a version of the site that you intend to upload to a web hosting service, Use Shared Libraries should be checked.
| Scenario | Recommendation |
|---|---|
| Making a site that will be uploaded to a web server | Checked |
| Making a site that will be distributed via removable media | Unchecked |
| Making a site for use on your PC and you have an active Internet connection | Checked |
| Making a site for use on your PC and you do not have an active Internet connection | Unchecked |
Add JSON-LD Metadata
When Add JSON-LD Metadata is checked, GedSite adds JSON-LD metadata to the page, writing a Person record for each person on the page. This metadata may be used by search engines or other tools.
ORA, the Online Repository Assistant, uses the metadata to influence its Control Panel contents. This capability is mostly intended to allow ORA users to use its Search Targets facility when visiting sites created with GedSite.

Family History Hosting
The following properties are used by the Family History Hosting > Publish command to automate the publishing process for Family History Hosting customers.
The Publish command removes the guesswork from maintaining the public version of your site. It keeps track of which files need to be replaced, and avoids transferring large images that have not changed. It compresses HTML files into one or more ZIP files, and transfers the ZIP files in order to reduce FTP overhead. The result is a faster, more reliable upload process that is easier to use than manual methods.
Family History Hosting customers receive an email message that indicates how to set the properties below. Please refer to that message when setting these properties.
FHH ID
The FHH ID indicates the Family History Hosting server where your web site files reside. This value will be a number.
Upload Method
The Upload Method property controls which method GedSite will use to upload the main HTML files for the web site. The default is Compressed Archive, a method where GedSite compresses the files and uploads them via ZIP files. This reduces the communication overhead but requires special support on the server.
Do not use the File by File method unless directed to by Family History Hosting support staff.
FTP Server
The FTP Server is the host name used for the FTP (file transfer) processing. The FTP Server's host name is "ftp." followed by your domain name. So, for example, if your domain was "example.com", enter "ftp.example.com" in the FTP Server property.
User Name
Enter the Control Panel ("cPanel") User Name that was assigned to you when you signed up for the Family History Hosting service.
Password
Enter the Control Panel ("cPanel") Password that was assigned to you when you signed up for the Family History Hosting service. If you have changed the password, enter the current value.
The password is not displayed in GedSite, but the password is stored in "plain text" (human readable) in the GedSite file. If you do not want to enter the password, leave it blank. GedSite will prompt you for the password when it needs it.
Subfolder
If the current GedSite file defines the contents for a subfolder on your site, enter the name of that folder.
Do not enter "www" or "public_html" to indicate the main folder. The main folder is not a subfolder: leave the SubFolder property empty to update the main folder.
Usage Notes
GedSite optimizes the upload process by:
- Uploading a compressed archive of files in several subfolders that GedSite knows contain mostly HTML files.
- Uploading only changed files in other subfolders.
To get the most out of these optimization steps, make sure that most if not all of the images used on the site are stored in subfolders. Store images used with the Image User Item in a subfolder of the Input folder.
When GedSite uploads a file that is in a non-HTML subfolder of the Output folder, it records the file date and file size in an "upload status" file. During all subsequent uploads, GedSite compares the file size and file date of the current version of the file to the last version that it uploaded. If either value has changed, or if GedSite has not uploaded the file before, it will upload the file. Otherwise, it skips the file because the current version is already on the server.
The upload status file is stored in the same folder as the GedSite file, and it has the same name except for the suffix "-files". If your GedSite file is "MySite.gsfile", the upload status file is "MySite-files.xml".
If you rename the GedSite file, or move it, you'll break the connection between the upload status file and the GedSite file, and GedSite won't know if the file has been uploaded before, or what version of the file was uploaded. That will trigger a re-upload of all the files.