GIGW 3.0 checklist: what government websites need before the STQC audit

Government websites and apps in India are expected to follow the Guidelines for Indian Government Websites and Apps (GIGW). Version 3.0 brings mobile apps into scope and aligns accessibility with current international standards. Before go-live, many sites go through a quality audit, commonly by STQC (Standardisation Testing and Quality Certification), and a security audit. Agencies that find the gaps early save weeks. This checklist follows the checks our GIGWCheck product runs.

Mandatory pages and links

Auditors expect a set of pages to exist and to be linked from every page, usually in the footer:

• Copyright policy.
• Hyperlinking policy.
• Privacy policy.
• Terms and conditions (or terms of use).
• Disclaimer.
• Help.
• Sitemap.
• Contact us.
• Feedback.
• Accessibility statement.

Website policies

Departments are expected to publish their website policies, typically on a Website Policies page: the Content Contribution, Moderation and Approval Policy (CMAP), the content archival policy, the content review policy and the contingency management plan. These are documents about how the site is run, so write them with the department, not just the agency.

Quality

• A last updated or last reviewed date shown on pages, generated by the content system.
• A Hindi version as well as English, with a language switch.
• Meaningful page titles, such as "Page name | Department name, Government of …".
• A meaningful meta description, with no template placeholder text.
• Site search.
• No broken internal links.

Accessibility

GIGW 3.0 aligns accessibility with WCAG at level AA. Automated tools find some issues; others need a person to check.

• The page language declared in the HTML (lang="en" or lang="hi").
• Alternative text on every image, and alt="" on decorative ones.
• A label on every form field.
• A "Skip to main content" link as the first focusable element.
• One h1 per page and headings without skipped levels.
• A Screen Reader Access page listing supported screen readers.
• Link text that describes the destination, not "click here".
• A notice when a link opens an external site in a new window.
• A mobile-friendly layout.
• Checked by a person: colour contrast of at least 4.5:1 for text, everything usable with the keyboard with visible focus, text resizable to 200 percent, and captions or transcripts for audio and video.

Security

• Every page served over HTTPS, and HTTP redirected to HTTPS.
• Strict-Transport-Security, X-Content-Type-Options and clickjacking protection headers.
• A Content-Security-Policy.
• No software version numbers in Server or X-Powered-By headers.
• Cookies set with Secure and HttpOnly.
• No mixed content (scripts, styles or images loaded over http://).
• A security audit by a CERT-In empanelled auditor before launch, with a valid safe-to-host certificate.

Lifecycle and hosting

• A named website owner or Web Information Manager with contact details.
• Content reviewed and archived according to the published policies.
• Hosting in a government data centre or with a MeitY-empanelled cloud service provider.

The items that most often fail

1. Missing policy pages, especially the hyperlinking policy and the CMAP.
2. No last updated date, or a hard-coded one that never changes.
3. Hindi pages that are partial or missing.
4. Images without alt text and form fields without labels.
5. No skip link and no Screen Reader Access page.
6. Security headers missing, or server versions disclosed.
7. Links that open new windows without warning.

How to prepare

Build the mandatory pages and the footer into the site template from day one, so every page has them. Make the last updated date come from the content system. Plan the Hindi version as content, with translators and reviewers, not as an afterthought. Run an automated pre-audit on every release, fix what it finds, and keep a list of the manual checks for a person to sign off. Book the security audit early: findings take time to fix and retest.

A worked example

An agency builds a state department's new website on a popular content management system. The automated pre-audit on the first build finds the hyperlinking policy and CMAP missing, no last updated date, no skip link, 40 images without alt text, an unlabelled search box, external links opening new windows without warning, and the web server announcing its version number. Most are template fixes: add the policy pages and links to the footer, generate the last updated date from the content system, add the skip link and labels, configure the server's headers. The alt text needs the content team. Fixing these before the auditor sees the site turns a likely second audit round into one.

Common mistakes

• Treating Hindi as a later phase. Missing or partial Hindi content is one of the most common audit findings.
• Copying policy pages from another department without adapting them, so they name the wrong department or contacts.
• Fixing issues on the home page only, when auditors sample inner pages too.
• Uploading scanned PDFs without text, which screen readers can't read.
• Leaving the security audit until the end, so its findings delay launch.

How to verify

Run an automated check on the home page and a sample of inner pages after every release, and keep the results. For the manual items, keep a signed checklist: someone has tested keyboard navigation, contrast, zoom to 200 percent and a screen reader on the main journeys. Review the policy pages with the department, and confirm the security auditor's safe-to-host certificate is current before go-live.

Mobile apps under GIGW 3.0

Version 3.0 brings government mobile apps into the same framework as websites. In practice that means apps are expected to meet the same principles: accessible to people using screen readers and other assistive technology, available in Hindi and English, secure in how they store and transmit data, and supported with clear contact, privacy and help information inside the app. For agencies, the practical consequence is that accessibility and language support need to be part of the app's design system from the start, and that security testing of the app and its back-end APIs should be planned alongside the website audit, not after it.

This checklist summarises common GIGW 3.0 and audit expectations. Always check the current guidelines published by the Government of India and the requirements given to you by the department and the auditor.