How to Scrape Goodreads Book Data: Ratings, Reviews

Before writing code, learn how Goodreads names things, because one distinction shapes the whole pipeline: a book is one specific edition (a hardcover, a paperback, an ebook), while a work is the abstract title across all its editions. Ratings and reviews aggregate at the work level, so the review query in section 7 needs a work ID, not the edition ID in the URL.

The URLs themselves are stable and predictable:

The numeric prefix is the real ID. The slug after the hyphen is cosmetic, so https://www.goodreads.com/book/show/2767052 loads the same page as the pretty URL. Book 2767052 is The Hunger Games by Suzanne Collins, and it's the working example throughout this guide.

Here's the data you can realistically collect, and the best source for each:

The pattern to internalize: Goodreads hands you structured JSON on the book page. Parsing rendered HTML with CSS selectors is the fallback for the older pages (lists, author, shelves), not the first move for books.

For years the standard answer to "how do I get Goodreads data" was the official REST API. That answer expired. Goodreads announced it would stop issuing new API keys as of December 8, 2020, and began retiring the public developer API for good. If you're starting a project today, you cannot get a key, existing integrations were told to expect deprecation, and the old endpoints have grown unreliable.

That leaves three practical options, and this guide covers all of them:

1. Scrape the live Goodreads pages for the data that is genuinely unique to Goodreads: its large-sample aggregate rating, its review corpus, and its Listopia rankings.
2. Pull the plain book facts from open sources (Open Library and the Google Books API) instead of scraping them, which is faster, free, and clearly licensed. See section 10.
3. Combine both in a hybrid pipeline so you spend scraping budget only where you have to. See section 11.

One more thing worth knowing up front: Amazon has owned Goodreads since 2013. That matters for two reasons. The Terms of Service inherit Amazon's stance on automated access, and the book identifiers you'll see inside the page carry Amazon work and book IDs (more on that in section 6). If you already scrape the retail side, our guide to scraping Amazon product data shares a lot of the same defensive habits.

Start here, because the answer changes your design. Goodreads' Terms of Service prohibit accessing the site with automated tools or scraping it without permission, mirroring Amazon's broader conditions of use. That's a contract term. Breaking it can get your accounts and IP ranges blocked and, in some jurisdictions, expose you to a breach-of-contract claim.

Three separate ideas are easy to conflate, so keep them apart:

• Public access versus contract. In the United States, courts (notably hiQ Labs v. LinkedIn) have held that scraping publicly available data is not by itself a Computer Fraud and Abuse Act violation. That is not a green light on the site's terms, and it says nothing about copyright.
• Facts versus expression. A rating number, a page count, an ISBN, and a publication date are facts, and facts generally are not copyrightable. A reviewer's written review is creative expression, and it is their copyright. Storing and republishing review bodies carries real exposure that storing a rating number does not.
• Personal data. Reviews come attached to real usernames, avatars, and profile links. Skip that PII unless you have a specific, lawful reason to keep it. Collecting a star score and the review text for aggregate analysis is very different from harvesting a directory of reviewers.

Practical takeaway: get the plain book facts from the open sources in section 10, scrape Goodreads only for its distinctive data, read and respect robots.txt, pace your requests, cache aggressively, and don't redistribute copyrighted review text. None of this is legal advice. Our guide on ethical scraping and rate limiting goes deeper on staying on the right side of the line.

Open any Goodreads book page, view source, and search for application/ld+json. Goodreads embeds a schema.org Book object in the page for search engines, and it's server-rendered, so it sits in the initial HTML before any JavaScript runs. That one detail saves you money: you don't need a headless browser to read ratings.

Here's the shape of the block. The numbers are a snapshot from one fetch, since ratings move constantly:

{
  "@context": "https://schema.org",
  "@type": "Book",
  "name": "The Hunger Games",
  "image": "https://images.gr-assets.com/books/....jpg",
  "bookFormat": "Hardcover",
  "numberOfPages": 374,
  "inLanguage": "English",
  "isbn": "9780439023481",
  "author": [
    { "@type": "Person", "name": "Suzanne Collins",
      "url": "https://www.goodreads.com/author/show/153394.Suzanne_Collins" }
  ],
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.34,
    "ratingCount": 9400000,
    "reviewCount": 235000
  }
}

Note the two count fields, because people confuse them constantly. ratingCount is how many people tapped a star score. reviewCount is the much smaller number who wrote text. On a popular title that gap is enormous, often 30 to 1, and the distinction matters if you're computing engagement or sampling reviews. Parsing this is a few lines:

import json
from bs4 import BeautifulSoup

def as_list(value):
    if value is None:
        return []
    return value if isinstance(value, list) else [value]

def parse_jsonld(html):
    soup = BeautifulSoup(html, "html.parser")
    block = None
    for tag in soup.find_all("script", {"type": "application/ld+json"}):
        data = json.loads(tag.string)
        if data.get("@type") == "Book":
            block = data
            break
    if not block:
        return {}
    rating = block.get("aggregateRating") or {}
    return {
        "title": block.get("name"),
        "format": block.get("bookFormat"),
        "pages": block.get("numberOfPages"),
        "language": block.get("inLanguage"),
        "isbn": block.get("isbn"),
        "authors": [a.get("name") for a in as_list(block.get("author"))],
        "rating": rating.get("ratingValue"),
        "rating_count": rating.get("ratingCount"),
        "review_count": rating.get("reviewCount"),
    }

The loop matters: a Goodreads page can carry more than one JSON-LD block (a BreadcrumbList sits alongside the Book), so filter on @type rather than grabbing the first one. This handles the headline fields for title, ratings, and edition metadata in one shot, with no selector maintenance. What it does not give you is the star histogram or the reviews, which live one level deeper.

Reading JSON-LD is easy once you have the HTML. Getting that HTML at volume, from an Amazon-owned property that rate-limits by IP, is the hard part. The SparkProxy Scraping API takes a target URL and handles the proxy, rotation, CAPTCHA, and optional rendering. Base URL https://scrape.sparkproxy.io/api/v1, auth through the X-API-Key header.

A basic fetch:

curl "https://scrape.sparkproxy.io/api/v1?url=https://www.goodreads.com/book/show/2767052&render_js=false&country_code=us" \
  -H "X-API-Key: YOUR_API_KEY"

The same call in Python, wrapped so the rest of the guide can reuse it:

import requests

def fetch(url, render_js="false"):
    resp = requests.get(
        "https://scrape.sparkproxy.io/api/v1",
        headers={"X-API-Key": "YOUR_API_KEY"},
        params={
            "url": url,
            "render_js": render_js,   # JSON-LD is in raw HTML, so keep this off
            "country_code": "us",     # Goodreads localizes buy links and some fields
        },
        timeout=90,
    )
    resp.raise_for_status()
    return resp.text

html = fetch("https://www.goodreads.com/book/show/2767052")
book = parse_jsonld(html)
print(book["title"], book["rating"], book["rating_count"])

Watch render_js="false". The parameter defaults to true, and on the SparkProxy credit model a non-rendered request is 1 credit versus 5 for a rendered one. Because the JSON-LD and the __NEXT_DATA__ blob are both baked into the initial HTML, you pay the cheap rate for almost everything and only turn rendering on for the rare page that needs it. Across tens of thousands of books, that is the difference between a sensible bill and a silly one.

If you'd rather not touch HTML at all, the API's extract_rules parameter runs CSS selectors server-side:

import json

params = {
    "url": "https://www.goodreads.com/book/show/2767052",
    "render_js": "false",
    "extract_rules": json.dumps({
        "title": "h1[data-testid='bookTitle']",
        "rating": "div.RatingStatistics__rating",
    }),
}

One caveat, and it's the reason JSON-LD wins on the book page: Goodreads' redesigned pages are a React app whose class names are hashed and rotate between builds, so selector-based extraction needs babysitting. The JSON-LD stays consistent because Goodreads keeps it stable for Google. Prefer the structured block, and reach for selectors only on the older server-rendered pages (lists, shelves, author) where the markup is steadier.

The modern book page is a Next.js application, which means it ships a