Google Scholar Papers: Citations, Authors and Open-Access PDFs

Where the data comes from. This Actor searches the OpenAlex index of the scholarly record, not Google Scholar's own results page. The papers overlap heavily and the citation counts, authors, DOIs and PDFs are all here, but the ranking is OpenAlex's relevance, not Google's. If you need Google Scholar's exact ordering, this is the wrong tool.

Search 250 million academic papers by keyword and get them back as clean rows: title, authors, venue, year, citation count, DOI link, a freely readable PDF where one exists, and the abstract. No API key, no captcha, no login.

Give it one query or a batch of them. Every query returns its own ranked list, tagged with the query it came from, so a run over twenty topics stays separable when you load it into a sheet or a database.

What you get

• One row per paper, ranked per query, with position starting at 1.
• Citation counts in cited_by_count, which is the field most people actually came for. Populated on effectively every paper.
• Authors and venue in authors_venue, up to eight authors followed by the journal or conference and the year.
• A stable link in title_url: the DOI where the publisher registered one, otherwise the landing page.
• Open-access PDFs in pdf_url when a free copy exists. Roughly 45% of papers have one. It is never a paywalled page dressed up as a download.
• The abstract, not a truncated preview, in snippet. Present on roughly 60% of papers, which is what publishers have released.
• An optional language filter, so a query can be restricted to papers published in Dutch, German, Spanish and so on.

Why this rather than scraping Google Scholar

Google Scholar has no API and rate-limits hard on the IP address. A scraper pointed at it works for about twenty requests from a clean address and then returns a captcha page, and the block is on the address, so neither a cookie nor a bigger proxy pool clears it. That is why so many "scholar scraper" listings quietly return empty runs.

This Actor reads OpenAlex instead, an open index of the scholarly record covering 250M+ works with citation graphs, author disambiguation and open-access links. It answers every request. The practical difference for you is that a run returns papers rather than a rate-limit page, and the abstract arrives in full instead of as a two-line snippet.

What it is not: Google Scholar's own ranking. If you need that exact ordering, this is the wrong tool. If you need the papers, the citations and the links, this returns more of them, more reliably.

Input

Field	Type	Required	Default	What it does
queries	array	yes	["large language models"]	One or more search queries. Each returns its own ranked list
pages	integer	no	1	Result pages per query, 10 papers each. Max 10, so up to 100 papers per query
language	string	no	–	ISO code (en, de, nl…) to return only papers in that language. Empty searches every language

Example input:

{
  "queries": [
    "large language models",
    "CRISPR gene editing"
  ],
  "pages": 2
}

That run returns 40 rows: twenty per query, ranked.

Output

One dataset row per paper:

{
  "position": 1,
  "title": "Quantum Computing in the NISQ era and beyond",
  "authors_venue": "John Preskill - Quantum - 2018",
  "year": 2018,
  "cited_by_count": 8690,
  "title_url": "https://doi.org/10.22331/q-2018-08-06-79",
  "pdf_url": "https://quantum-journal.org/papers/q-2018-08-06-79/pdf/",
  "snippet": "Noisy Intermediate-Scale Quantum (NISQ) technology will be available in the near future...",
  "search_query": "quantum computing"
}

Use cases

Literature reviews that need to be repeatable. A review is only defensible if someone else can rerun the search. Store the queries and the run date and the whole result set reconstructs, with citation counts as they stood on that day.

Finding what to read first. Sorting a topic by cited_by_count puts the papers the field actually built on at the top. For an unfamiliar subject that ordering is worth more than relevance ranking.

Tracking a research area over time. Run the same queries monthly and diff cited_by_count per DOI to see which work is gaining traction, and which papers are new to the field since last month.

Building a reading pipeline. pdf_url gives a direct link to the papers you can actually open, so a downstream job can fetch and index the full text without a librarian's login.

Competitive and technical due diligence. Checking who publishes on a technology, where they publish, and how often they are cited is a fast read on whether a claim has a research base behind it.

Pricing

$0.001 per paper returned. You pay for papers, not for runs, and there is no subscription. A 100-paper run costs $0.10. Queries that return nothing are not billed.

Free-plan Apify users receive the first 10 rows of each run. Any paid plan removes that limit.

Limits and gotchas

• Not every paper has a PDF or an abstract. Around 45% carry a free PDF and 60% an abstract, because that is what publishers released. Blank fields are the honest answer, not a failed run.
• Ranking is relevance, not Google Scholar's ranking. The set of papers overlaps heavily; the exact order does not.
• Citation counts are a snapshot. They change as the index updates, so record the run date if the number matters to your argument.
• Preprints and published versions can both appear for the same work. Deduplicate on title_url if that matters to you.
• Maximum 100 papers per query (10 pages of 10). Split a broad topic into narrower queries rather than expecting one query to return a whole field.

FAQ

Do I need an API key or an account anywhere? No. You supply queries and nothing else.

Does it cover my field? The index spans every discipline, including the humanities and non-English publishing, which is where Google Scholar's coverage is thinnest.

Can I restrict results to recent work? Not directly in the input yet. Pull the papers and filter on year, which is populated on 99% of rows.

Why is snippet empty on some rows? The publisher did not release an abstract for that work. Nothing was lost in transit.

Can I search in a language other than English? Yes. The query text can be in any language, and language restricts the results to papers published in one.

How many papers can one run return? 100 per query, and a run can carry many queries, so a twenty-query run returns up to 2,000 papers.