How is a government website different from a corporate website?
Key takeaway
Beyond presenting information and projecting the agency's image, a government website exists to deliver public information and digital services, so planning has to cover users, usability, accessibility, information security, data continuity, and ongoing operations at the same time.
A corporate site may focus on brand, products, services, and business conversion. A government site, however, may serve the general public, specific service recipients, businesses, foreign nationals, researchers, or other agencies, and their goals range from simply finding information to looking up regulations, downloading documents, applying online, tracking cases, submitting feedback, filling in forms, searching data, or using other public services.
That is why government website development cannot start with “which blocks go on the home page?” It has to start with “what does a citizen come to this site to get done?”
The Government Website Service Management Guidelines currently published by the Ministry of Digital Affairs are built around the website lifecycle and divide government website services into six stages:
- 01
Positioning
- 02
Design and planning
- 03
Development
- 04
Data migration
- 05
Launch preparation
- 06
Operations
The guidelines also cover 11 management principles spanning positioning, usability, development environment, security, data migration, launch, and ongoing operations. What a government website project actually delivers, then, is not “a new web page” but a website environment that can keep providing public services.
Which user needs should government website planning confirm first?
Key takeaway
A government website's information architecture should start from the audiences and the tasks they need to complete, not from moving the agency's organisation chart into the site menu.
Inside an agency, people naturally think in terms of departments, offices, sections, and business units. A citizen arriving at the site usually does not start with “which section handles this?” They start with:
- Where do I apply?
- Which document am I looking for?
- How do I get this subsidy?
- Where do I check the status of my case?
If the site is structured entirely around the internal organisation, users first have to understand how the agency divides its work before they can find anything. So early planning should confirm:
- Who are the users?
- Which tasks do they most often need to complete?
- Which information matters most to them?
- How many steps from the home page does it take to reach the service they need?
- Is the experience consistent across devices?
The Government Website Service Management Guidelines currently place explicit emphasis on user-centred design, recommending user research to understand audience needs and pain points before positioning and designing the site. They also recommend a clear and consistent interface, humane search, and mobile-friendly design such as responsive web design (RWD).
This also means a redesign cannot simply “refresh” the old site. If the real problems were that information was hard to find, menu categories did not match how citizens think, search results were unhelpful, or the site was awkward on a phone, a new visual design alone leaves all of them in place.
| Area | Questions to ask before development |
|---|---|
| Purpose | Which public information or services will this site mainly provide? |
| Audiences | Who will use it, and what does each audience mainly need? |
| Tasks | What do citizens most often need to get done? |
| Information architecture | Can users quickly make sense of the menus and categories? |
| Mobile | Can the main features be read and used fully on a phone? |
| Accessibility | Are UI, content, and interactions accessible from the design stage? |
| Security | Does the site involve login, personal data, forms, applications, or integrations? |
| Data migration | Which old-site content is kept, retired, or reorganised? |
| Launch | How will the production environment, data, features, and testing be confirmed? |
| Operations | Who manages content, systems, and security updates after launch? |
This is not a fixed requirements list that every government website must adopt by law. It is a planning aid for checking whether the site's scope is complete before outsourcing the build.
When should accessibility work on a government website start?
Key takeaway
Web accessibility is best built in from the information architecture, UI/UX, and front-end development stages, not retrofitted after the site is finished.
That is because accessibility reaches far beyond “larger text.” For example:
- Can a button be operated with the keyboard alone?
- Is the focus order sensible?
- Do images carrying important information have appropriate text alternatives?
- When a form entry is wrong, does the user know where the error is?
- After an interactive menu expands, can someone using assistive technology tell what state it is in?
- Do heading levels and HTML structure correctly express the relationships between pieces of information?
Every one of these touches UI/UX and code. The Ministry of Digital Affairs' current government website management guidelines explicitly require agencies to provide a site environment that people with disabilities can use easily, in line with the web accessibility guidelines. In the current accessibility guidelines, “keyboard operable,” for instance, requires that site functions can be operated through a keyboard interface, precisely so that users relying on different input methods and assistive technologies can complete their tasks.
The 2026 accessibility guidelines are changing versions
This matters especially for government websites being tendered or built right now.
On May 29, 2026, the Ministry of Digital Affairs published a revised version of the Web Accessibility Guidelines and announced that from November 30, 2026, certification mark testing will use the Web Accessibility Guidelines (115.11). From the same date, new mark applications under version 110.7 are no longer accepted, while marks obtained under the earlier version on or before November 29, 2026 keep their three-year validity.
So if a project expects to launch and apply for the mark at the end of 2026 or later, its requirements and development approach should not rely only on the version that is about to stop accepting new applications. This is an easy thing to miss in government website development: the basis for development cannot be judged only at tender time; it has to consider the version that will apply at acceptance and go-live.
In addition, under the current explanations of the Regulations on Web Accessibility Testing and Certification Mark Issuance for Government Agencies, Institutions, and Schools, governments at every level and their subordinate agencies, institutions, and schools should test the accessibility of their information service websites themselves and register with the competent authority. Which level a specific project must reach, A, AA, or AAA, still depends on the project's needs, the tender documents, and the applicable rules, so “every government website must be AA” should not be treated as a universal rule.
What should a government website consider for security and personal data?
Key takeaway
As soon as a government website goes beyond static content and starts to involve login, online applications, personal data, databases, or system integrations, security directly shapes the requirements and the system architecture.
A site that simply publishes agency information and a site where people register, upload documents, enter personal data, track cases, and log in to view their own information may both be called “government websites,” but the security risks they have to handle are completely different. So before development, confirm:
- What data will the site collect?
- Which information requires login to access?
- What user roles exist?
- Is there a back-office administration function?
- Does it integrate with other databases or APIs?
- What is the impact if the system is attacked or goes down?
Article 10 of the current Cyber Security Management Act provides that, within its scope, when a government agency or a specific non-government agency outsources the construction, operation, or services of an information and communication system, it must select an appropriate contractor, require the contractor to establish an effective cybersecurity management mechanism and supervise its implementation, and set out the rights, obligations, and liability for breach in a written contract.
Article 11 of the current Regulations on Classification of Cyber Security Responsibility Levels also provides that information and communication systems developed by an agency itself or through outsourcing must complete system protection requirement classification as required and apply control measures according to the corresponding protection baseline.
This does not mean every government website can be handled with the same set of security requirements. The real task is to first confirm which systems and data the site contains, then confirm which security requirements actually apply to that project. The Government Website Service Management Guidelines currently list the Cyber Security Management Act, the Personal Data Protection Act, the Freedom of Government Information Law, and the web accessibility guidelines among the rules to be confirmed during government website development.
So security and personal data are not “acceptance items” added after the site is built. They are part of the development requirements from the start.
How should technology and system architecture be planned?
Key takeaway
Technology choices for a government website should weigh not only development speed but also compatibility, licensing, security, future maintenance, and how easily the site can be extended.
A government website is rarely used for just a year. What development really needs to avoid is discovering after launch that:
- only the original vendor can change it,
- the framework is no longer maintained,
- third-party package licences are unclear,
- features break after a browser update, or
- the code structure is hard for anyone else to take over.
The current Government Website Service Management Guidelines list “prioritising open-source tools and systems, and using a development environment compatible with international standards” as one of the management principles. They also recommend cross-browser compatibility and extensibility, adoption of international standards, and, where third-party packages, frameworks, or libraries are used, an inventory of their content, origin, and licensing, with continued attention to accessibility, privacy, and security.
This does not mean every government website must use the same CMS, language, or framework. What matters more is settling a few questions before development:
- Is the technology still actively maintained?
- Could another team reasonably take it over in future?
- Are the packages and their licences clear?
- Does the site support the main browsers and devices?
- Can the architecture support future feature growth?
- How will source code, documentation, and deployment be handed over at the end?
These questions usually affect the cost of running a government website over the next five years or more far more than the choice of a fashionable framework.
What should a redesign watch for in data migration and launch?
Key takeaway
A government website redesign is not copying every piece of old data to the new site. It is first deciding which information to keep and how to convert it, then making sure data, features, and URLs do not break when the new site takes over.
Many government websites accumulate years of press releases, announcements, regulatory documents, PDFs, event material, images, and legacy sections. Moving all of it untouched to the new site is not necessarily the best approach. Some content is outdated, some should be preserved but no longer belongs in the main navigation, and some needs to be reclassified on the new site. So inventory the data before migrating it.
The current Government Website Service Management Guidelines treat data migration as its own stage in the website lifecycle and require attention to continuity of data and services. For migrating an existing site, they recommend inventorying the old site's data structure and volume, confirming a migration list, and defining how the old and new directories and data correspond.
Data migration also runs into another problem: URLs. If addresses that citizens, search engines, other government sites, or external documents already cite all stop working after the redesign, users may no longer be able to find the original material. So before the switch, besides the data itself, inventory the important URLs and their content mapping and plan redirects or other transition measures as needed. The official FAQ for the accessibility mark currently also reminds agencies that during a transition period, the old site should provide redirects or a corresponding notice.
What else can be confirmed before go-live?
Go-live is more than “switching the DNS.” The government website operations exchange platform currently treats launch preparation as a separate stage and notes that stability, performance, security, databases, and data synchronisation in the production environment all need consideration beforehand. So at minimum, confirm:
- Are the features complete?
- Is the production data correct?
- Is the data migration complete?
- Are user permissions correct?
- Do mobile devices and the main browsers work properly?
- Are the accessibility requirements met?
- Is the required security work done?
- Is the production configuration correct?
- How will the old and new sites be switched?
- Is there a rollback or contingency if something goes wrong?
A mature launch plan asks “what do we do if something goes wrong on switchover day?” rather than only “what time can we go live?”
When are government website requirements ready for development?
Key takeaway
You do not need every screen designed before development assessment can begin, but there should at least be basic agreement on the site's purpose, users, information architecture, main features, data, accessibility, security, migration, and acceptance.
A few questions give a quick read.
Why is the site being redesigned or built?
If the only answer is “the current site is old,” keep asking. Is it that:
- it is hard to use on a phone?
- citizens cannot find information?
- the CMS is hard to maintain?
- it cannot offer new online services?
- the technology and security no longer meet requirements?
Different problems lead to completely different project scopes.
What do users need to get done?
Who is the main audience, and what are the three to five most important tasks they complete after arriving?
Are the content and feature boundaries clear?
- What is just content?
- What needs search?
- What needs a form?
- What needs login?
- What is really already an information system?
Are the rules built into the requirements?
Have accessibility, security, personal data, and any other case-specific requirements been identified early on?
What happens to the old site's data?
Which content is migrated, retired, archived, or reorganised?
How will acceptance work?
Beyond “the screens match the design,” which features, compatibility, data, accessibility, or security requirements have to be confirmed?
If most of these questions have answers, the project is no longer just “we want a new government website.” It is becoming a build scope that can be estimated, designed, and developed. If many are still open, there is no need to work out every technical answer alone first. It is usually better to complete the user requirements, information architecture, and inventory of existing content and systems, then form the formal site specification step by step.
Frequently asked questions
Do not treat “every government website must reach AA” as a universal rule. The current system has A, AA, and AAA levels, and governments at every level together with their subordinate agencies, institutions, and schools must carry out accessibility testing and registration for their information service websites under the relevant regulations. The level a specific project must reach still depends on the agency's requirements, the tender documents, and the applicable rules.
Do not wait until the site is finished to catch up on the rules
From audiences, information architecture, UI/UX, accessibility, and security to migration of existing data and go-live, every requirement of a government website can directly shape its design and technical architecture.
The earlier these conditions are pinned down in the project, the lower the risk of having to rework the interface, code, or data structure after the site is already built.
Regulations and standards cited
- Government Website Service Management GuidelinesGovernment Website Operations Exchange Platform
- Web Accessibility GuidelinesMinistry of Digital Affairs
- Regulations on Web Accessibility Testing and Certification Mark Issuance for Government Agencies, Institutions, and SchoolsMinistry of Digital Affairs
- Cyber Security Management Act, Article 10Current statute
- Regulations on Classification of Cyber Security Responsibility Levels, Article 11Current statute
These are the regulations and standards cited at the time of writing. Rules may be revised; always check the latest official announcement before relying on them.