Technical Considerations in SEO for Government

This article is part of the SEO for Government Series. You can find the other articles by clicking on the following links:

What is SEO for the Government? The Why

Competitors in SEO for Government

Commercial Considerations in SEO for Government

The Fundamental SEO

If you are reading this, I will assume that you have some understanding of how SEO works. The fundamentals of SEO apply to Government sites too, and I'd like to expand about some specific needs for these websites.

Technical performance

Doing regular SEO, you would assume that some users are more important to you than others. Because they are most prone to convert/buy, or maybe you can infer they have a higher income based on the combination of browser/device.

However, when dealing with such an enormous potential user base, this is not the case. You can not just assume that your "important" users will have a specific device, operating system, or browser. Top-notch performance, fast websites, and efficient rendering are part of the equation. If you care about digital inclusion, especially for people with a lower income, you have to design with low-price devices and slow networks in mind.

In my opinion, these are some basic technical concepts that you need to keep in mind.

Responsive Design (No AMP, which is dead anyway): At least four different screen resolutions for QA, and support for many browsers as possible, not just Chrome/Safari.

Server-Side Rendering: Again, since you cannot assume that some devices will deal with heavy JS, it is better to have those at a minimum and manage all workload from the server-side.

Service Continuity

You need to prepare the website for high loads at specific moments. Some events are easy to spot beforehand (the period of taxes, for instance), and others appear suddenly (such as natural disasters).

A hybrid cloud that creates (and removes) on-demand instances could be an excellent strategy to manage sudden demand peaks, but it depends on the budget and IT capabilities.

Global CDNs are, counterintuitively, less useful in these cases because you do not expect users from all around the world, but the exact opposite: all of them will come from the same country (or location), so there is no point in preparing for a global audience. Depending on the country, some CDNs country-level implementations can be helpful, but I don't consider them the first item on my list.

(Lack of) Accessibility Standards

Not all countries provide an actual set of technical standards. In my experience, it is rare to have such standards at all. For this reason, I recommend adhering to the most strict level of accessibility and compatibility that the budget allows, aiming to a AAA accessibility standard.

Integrations

Being able to combine different systems with the public website is a must in all cases. It would be best if you had an experienced team in creating sites and integrating them with the current systems in use. The most common integrations are CRMs and ERPs.

Note: if you are a vendor, there are a lot of chances of winning (or losing) the proposal based on your experience in the specific integrations and back-end software and platforms, instead of your Design/UX/SEO capabilities.

Headless CMS

Government websites are a case where I definitively recommend a headless CMS. Not for their SEO advantages (none), but because it is way easier using a headless architecture to manage websites with this amount of information, updates, and load.

A Headless CMS will also allow for updating government apps, physical screens, and multiple websites at the same time without requiring an army of content managers.

An example would be loading the same component with information about the pandemic on multiple websites, regardless of their TLDs. This way, you need to update just one repository to provide accurate and exact information through several channels. In case of an error or update, fixing that unique container will simultaneously update the information on all websites, saving time and effort and increasing efficiency.

Note: In this article, you can find my specific recommendations for SEO in Headless CMS

Workflows & Users/Privileges

Who can do what and when is more complicated than what you might think. Monolithic CMS as WordPress or Drupal provide a too basic level of management of roles and privileges. I can assure you that it will not be good enough to manage a website of these characteristics.

Understanding the specific content creation process and people involved will help you define each role's workflow and privileges. Still, I suggest you have restricted access to publish content components but relatively open permissions to modify and update those components.

Schemas

Frequently Asked Questions is, by far, the most helpful schema that you should implement. In some way, most government websites' content is informative and fits perfectly with this schema. Since you are not necessarily looking for web traffic, it is acceptable to have the answer directly in the SERP instead of moving the user to the website. Of course, you can still analyze the SERPs to know if you are there or not.

Google Business Profile (ex-Google my Business): Currently, government or state entities are treated as regular businesses in GBP. This means you can verify several physical locations at the same time.

Entities/Persons: In some cases ca be helpful to also add information and specific Schemas for the organization or relevant people working on them.

Is something missing?

It is probably a lot of specific information missing. I'll try to update this post when needed, but if you have specific questions, you can drop me a message on Linkedin and I`ll try to help.