01 Checklist · research websites

Research website checklist: can people find, read and cite your work?

A research website works when policymakers, journalists, researchers and funders can find a publication in a few clicks, read it on any device without a PDF, cite it correctly and reuse its data. This research website checklist covers five phases, from content audit to running the site, with a pass/fail test per item. Score your site in about 15 minutes.

For think tanks, research institutes, development nonprofits and public digital infrastructure bodies

Score your siteKeep a copy
Written by

Siddharth Kajaria, Founder and CEO

Last updated

Illustration: an open report with a magnifier, a phone, a tablet and a ticked checklist

02 The checklist

How does your research website score?

Tick each test your site passes today. The twenty tests run in five phases, in the order a rebuild meets them, from auditing what you have to running the site.

Phase 1. Audit what you have

The tests2 tests

  1. 01 Inventory

    What good looks like
    One list of every site, microsite, PDF library and dashboard you run, with an owner for each.
    Why it matters
    You cannot plan a rebuild, or redirect a link, for a site nobody remembers running.

  2. 02 Audiences

    What good looks like
    A written main task for each audience: what a policymaker, a journalist, a researcher and a funder each come to do.
    Why it matters
    Navigation built around your structure serves your staff; navigation built around these tasks serves your readers.

How we approach it Mapping every site and tool before a rebuild, on policy and research

Phase 2. Plan the structure

The tests3 tests

  1. 03 Content model

    What good looks like
    Reports, people, topics, programmes and datasets are connected records, not separate pages.
    Why it matters
    The connections are what let a reader move from one report to its authors, its topic and its data.

  2. 04 Taxonomy

    What good looks like
    A short list of topics and types, with one tag for each idea and a named owner.
    Why it matters
    Two tags for one idea split your work across two lists, so filters and search miss half of it.

  3. 05 Ecosystem decisions

    What good looks like
    A decision for every microsite and tool: fold it in, keep it with the shared design, or archive it with its links redirected.
    Why it matters
    A microsite tied to a grant can vanish when the grant ends, and every link to it breaks.

How we approach it Research content systems

Phase 3. Make it findable and readable

The tests8 tests

  1. 06 Publication library

    What good looks like
    One library that holds every publication and filters by topic, type, year and author.
    Why it matters
    Readers who cannot narrow a long list give up, and one library gives search engines one place to find your work.

  2. 07 Search

    What good looks like
    Site search that finds a report by its title and by its author's name.
    Why it matters
    A visitor who searches usually knows what they want, so a miss reads as "it is not here".

  3. 08 People pages

    What good looks like
    A page for every researcher, filled from the publications they are tagged on.
    Why it matters
    Journalists and funders often look for a person, not a paper, and lists kept by hand go stale.

  4. 09 PDF-to-web

    What good looks like
    The key findings of each report as a web page, with the PDF as a download beside it.
    Why it matters
    A PDF is hard to read on a phone, and its findings are harder for search engines and AI answers to quote.

  5. 10 Citation and reuse

    What good looks like
    A "cite this" line, a stable URL and a stated licence on every publication.
    Why it matters
    A citation that breaks, or a licence nobody can find, stops your work being cited and reused.

  6. 11 Data

    What good looks like
    Every dataset downloads with a methodology note, and every dashboard shows a "last updated" date.
    Why it matters
    Data without its method is hard to trust, and a dashboard with no date can be read as current when it is not.

  7. 12 Accessibility

    What good looks like
    Templates built for keyboard and screen-reader use. For a government-linked body, check whether GIGW applies.
    Why it matters
    Readers who use a keyboard or a screen reader need to reach the same research as everyone else.

    An automated check finds only part of the issues; a full audit needs a specialist.

  8. 13 Languages and speed

    What good looks like
    Key pages in the languages your audience reads, and a library that loads quickly on a phone.
    Why it matters
    A page in the wrong language is a page skipped, and a slow library loses readers on a mobile connection.

How we approach it Research websites

Phase 4. Move without loss (if you are rebuilding)

The tests2 tests

  1. 14 Redirect map

    What good looks like
    A sheet that maps every old URL to its new one, checked before launch.
    Why it matters
    Old links in citations, news stories and search results keep working, and keep their standing in search.

  2. 15 Ranking baseline

    What good looks like
    A record of your indexed pages and top search queries, taken before launch.
    Why it matters
    Without a before, you cannot show that the move kept your search traffic, or find what it lost.

How we approach it Moving a research site, on research websites

Phase 5. Run it

The tests5 tests

  1. 16 Publishing

    What good looks like
    Editors publish, tag and feature a new report themselves.
    Why it matters
    If every report waits for a developer, publishing slows and the site falls behind the work.

  2. 17 Measurement for funders

    What good looks like
    Downloads, searches and sign-ups reported by programme.
    Why it matters
    Funders ask what a programme's research reached, and the website can answer with numbers.

  3. 18 Ownership

    What good looks like
    The code, the content, the domain and every admin account held by your organisation.
    Why it matters
    When a supplier or a staff member leaves, the site should not leave with them.

  4. 19 Freshness

    What good looks like
    Each dashboard updated by a named person or an automated pipeline.
    Why it matters
    A dashboard nobody updates goes out of date while still looking current.

  5. 20 Consent

    What good looks like
    Newsletter and event forms that say what the data is for, and keep a record of consent.
    Why it matters
    Data protection law sets how sign-up data may be collected and used: the DPDP Act 2023 in India, and the GDPR for international audiences. The current texts are on meity.gov.in and eur-lex.europa.eu.

How we approach it Publishing workflows, on research content systems

03 Your score

What does your score mean?

Your score puts the site in one of three bands, and each band has a next step. Fix the gaps in phase 2 before phase 3: search, filters and author pages cannot work without a content model and a tag list.

Taking it to your board or funder? Share the score and the tests you failed: the failed tests are the brief for the work.

0–9 · Buried
The work exists, but most readers will not find it. Start with phase 2, the content model and the tag list, before any redesign.
10–15 · Findable with effort
The basics are in place. Fix the failed tests in phase 3 next, because they decide whether a reader gets from a search to a citation.
16–20 · Easy to find and cite
Keep it there: protect the redirect map at every change, and keep a named owner on every dashboard.

04 Where it is covered

What does fixing it involve?

Each phase has a page that shows how we approach it, with the work behind it.

  • Phases 1 and 2, audit and plan. How a whole set of sites, microsites and tools is mapped before anything is built: policy and research.
  • The content model and tags. Research content systems, with Crime and Punishment for Vidhi Centre for Legal Policy: a database of 7,305 crimes across 370 central laws that Tailwebs built and maintains.
  • Phases 3 and 4, the library, search and a move without loss. Research websites, with GFC's whole digital ecosystem, CSEP's website redesign, the MobiliseHER website, and the websites Tailwebs built for MOSIP and the eGov Foundation: MOSIP's brand website, and egov.org.in, with help on egov.global.
  • The data tests. Data portals and dashboards, with the dashboards for CEEW's Green Finance Centre (GFC) and the MobiliseHER gender-mobility dashboard for WRI India.
  • Open standards and shared platforms. Websites for digital public goods and their communities.
  • What it costs. A Discovery Sprint is ₹1.5–3 lakh, and the Research Website package ₹6–20 lakh; both are on our pricing page, or book a call to talk it through.

05 The PDF

Want a copy for your next review?

Everything on this page stays open to read and score, with no sign-up. To take it into a board or funder review, keep a copy of the page with your ticks on it.

Your browser's print option saves this page as a PDF, with every phase open and every test on it.

06 FAQ

Questions about research websites.

What makes good research organisation website design?
One where people can find a publication in a few clicks, read it without opening a PDF, cite it correctly and reuse its data.
Which accessibility standard should a think tank or policy website meet?
Most aim for the Web Content Accessibility Guidelines (WCAG). Where the site is government-linked or government-funded, also check whether GIGW applies.
What should we fix first?
The content model and taxonomy, because search, filters and author pages all depend on them.
Can our team publish without a developer?
Yes, when the site has a clear content model and a publishing workflow, and the team is trained at handover.
Do I need to give my email to use the checklist?
No: the checklist on this page is open to everyone.