weibo-trending-hot-search keeps a dated archive of Weibo hot search terms

An hourly scraper that writes Weibo hot search down by the day

weibo-trending-hot-search answers one narrow question: what was trending on Weibo at a given moment in the past. The README gives the scope precisely. The repository records Weibo hot searches starting from 2020-11-24, scraping the data once an hour and archiving it by day. That phrasing rules out several things a reader might assume. There is no live endpoint to poll, no ranking computed on demand, and no application server anywhere in the tree. The deliverable is committed files.

That design suits a particular user. Researchers, media analysts and anyone studying how Chinese attention shifts want a history they can diff, not a chart that redraws itself. Because each scrape lands in a file, two people looking at the same day later see the same list. A project that exposed only a current ranking would be useless for that.

What you get in return is a raw, unprocessed Chinese-language ranking. The current README list mixes a political slogan at the top with a sports league result, a handset launch rumor and at least one plainly commercial entry. If you plan to build a signal out of this, that mixture of official, editorial and promotional terms is the first thing you have to handle yourself.

raw/ and archives/ split the working copy from the dated history

The top-level entries of the repository make the storage model visible. Alongside the usual project files there are two directories that do the actual work, raw/ and archives/. The README points readers at the archive directory with a link labelled as the archive location, and the daily grouping means history is browsable by date.

That split has a practical consequence for anyone consuming the data. A day with no scrape is a missing day, visible as a gap in the archive rather than as a subtle corruption inside a file. If you are walking the archive linearly, you can tell exactly where the record stops. If you are diffing two days, you compare two files.

The remaining top-level entries are ordinary housekeeping: .gitattributes, .gitignore, .vscode/, .github/, LICENSE and README.md. The presence of .gitattributes means the tree carries some rule for line endings or file modes, which matters when you parse archived files across platforms. The README does not describe that file, so the exact rule is only visible by opening it. The .vscode/ directory suggests an editor configuration was committed, which is harmless but tells you the project was developed in a particular local setup rather than a fully neutral one.

main.ts, utils.ts and types.ts are the whole scraper

Only three source files carry logic, and each has an obvious role. main.ts is the entry point, utils.ts holds helper functions, and types.ts holds type declarations. Alongside them sits utils.test.ts, so at least part of the helper layer is covered by unit tests. That is a small, readable footprint: you can read the entire scraping and writing behaviour in one sitting.

The configuration lives in deno.jsonc, which follows the Deno project convention, and the primary language of the repository is TypeScript. The README does not reproduce the contents of deno.jsonc, so the task names, the script entry points and any dependency list are only knowable by opening the file. The README also does not state the command used to run the tests, so you cannot reproduce a green test run from the README alone.

A build badge at the top of the README points at a GitHub Actions workflow running against the master branch, the default branch of this repository. So there is continuous integration checking something on every push, which is a reasonable signal that the code compiles and that the tests run on a schedule tied to commits. It says nothing about whether the scraper still succeeds against the live site, since that is a network dependency the badge cannot observe.

Reading the current list straight out of the README

You do not need to run anything to read a copy of the list. The README embeds the most recent one under a heading for the day's popular searches, and the block is delimited by HTML comment markers that a script can find and replace:

<!-- BEGIN -->

The line immediately after that marker records the last update time in a fixed Chinese Standard Time format, which is the first thing to read when you want to know how fresh the list is. Below it comes a numbered list where every entry is a link into s.weibo.com with the term percent-encoded in the q parameter. Many entries also carry t=31, a band_rank value and Refer=top.

That is a genuine first use for a new reader: open README.md, note the timestamp, and read the top of the list. Two details deserve attention before you trust the ordering. The first entry has Refer=new_time and no band_rank parameter at all, and later in the same list a band_rank of 1 reappears well past position 30, alongside a second entry that repeats band_rank=4. The visible ordering is therefore not a plain sort by band_rank, and a parser that assumes it is will mis-order results.

The README documents no install command at all

If you arrived expecting a package to install, there is none. The repository publishes no GitHub releases, and there is no npm or other registry entry referenced anywhere in the README. What you get instead is a source tree that you clone and run with the runtime its configuration targets, with the actual commands defined in deno.jsonc.

Because that file is not shown, the honest way to write a tutorial here is to describe the verification steps rather than invent a command line. Clone the repository, open deno.jsonc to read the task definitions, open main.ts to see which entry point the scheduled job invokes, and read utils.ts to understand how the fetched list is turned into a file. The README gives no environment variables, no ports and no configuration keys, so there is nothing to set before a first run.

This absence is a real constraint for adoption. A scraper that depends on an external site tends to need tuning, and a tuning knob that the documentation does not name is a knob you will find by reading TypeScript. Readers who expect a quick install and immediate output will not get that here.

A committed history, not a published service

The maintenance picture is straightforward. The repository is not archived, and the last push was on 2026-10-20, so the hourly pipeline was still landing commits on that date. There are no tagged releases to track and no changelog to read, which means the only upgrade path is pulling the master branch and accepting whatever the newest commit contains. There is no published versioning scheme, so any external consumer has to pin to a commit hash on its own.

The licence is MIT. In practical terms that lets you read the archived files, reuse them in your own analysis and ship derived output, as long as the copyright notice and licence text travel with the redistributed portion. That is a statement about the licence text, not legal advice, and it matters more here than in many projects because the useful artefact is data that other people will republish.

What you inherit along with the data is the collection method. Anyone rebuilding a trend analysis from these files is also inheriting whatever normalisation, truncation and ranking rules the scraper applied, and those rules live in utils.ts rather than in any specification.

Where this archive stops being the right tool

Three use cases fail here. The first is live ranking. The pipeline runs hourly and then regenerates the README, so the freshest list you can read is already at least an hour behind, and the README documents no API, webhook or streaming interface to narrow that gap. Anyone who wants the current Weibo hot search at the moment of a request should read the site directly.

The second is structured measurement. The visible fields in the README are a rank, a term and a link. The README does not document search volume, category labels, sponsor flags or sentiment, and it does not describe a schema for the archived files, so you would be inferring field semantics from filenames and samples. The third is completeness guarantees. The README documents no retry policy, no failure marker and no backfill, so an archive entry tells you what was captured, not whether anything was missed that hour.

For readers comparing platforms, the README lists three sibling archives from the same author for a different site: zhihu-trending-top-search, zhihu-trending-hot-questions and zhihu-trending-hot-video. They apply the same committed-history approach to Zhihu, which makes them the closest comparison in the ecosystem, and they differ mainly in which source site and which content type they track.

Editorial conclusion

Adopt it if you need a reproducible, dated history of what trended on Weibo, and read the archives/ layout plus the raw/ tree before assuming a schema. Do not adopt it for live ranking, for structured search volume data, or for anything that requires a guaranteed hourly capture, since the README documents no API, no retry policy and no release artifacts. The first thing to verify is the actual shape of a file inside archives/ and the task names defined in deno.jsonc, because neither is described in the README.

Frequently asked questions

Official sources

1. Issues
2. justjavac/weibo-trending-hot-search on GitHub
3. License: MIT
4. README