Why does DBCC CHECKTABLE report errors on non-existent pages?

When I run DBCC CHECKDB, I get a slew of error messages like this:

Table error: object ID 2020918271, index ID 1, partition ID 72057594196590592, alloc unit ID 72057594190233600 (type In-row data), page (4:129574), row 0. The record check (valid UDT column) failed. The values are 3 and 0.

Right now I'm just trying to understand what this error means and how serious it is - it seems to be some checksum-related error and probably not that severe. Recent backups seem to have the same problem, but it's not a big deal either way because the data can be recreated from other sources.

Anyway, I'm trying to get to the bottom of this, maybe understand which rows are corrupted, if there's any particular pattern to it. When I run DBCC PAGE to see what's in there, such as the following statement:

DBCC PAGE('MyDB', 4, 129574, 3)

It shows nothing. Nada. Zip. Just the standard:

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

But no error and no page data. In fact, every single error that's coming out of CHECKTABLE has a file/page number for which I get this output from PAGE.

I'm also seeing the following error from the CHECKTABLE output, but only sporadically:

Table error: Object ID 2020918271, index ID 1, partition ID 72057594196590592, alloc unit ID 72057594190233600 (type In-row data). Page (4:129575) was not seen in the scan although its parent (4:129977) and previous (4:129574) refer to it. Check any previous errors.

It looks like it might be related, but I'm not really sure how. The UDT can be relatively large (about 5 KB), so maybe it's split across pages and one of the pages is missing? That's just a wild guess, though.

The number of errors coming out of CHECKTABLE also makes it look as if the entire table is like this, but I know that's not the case, because I can read the data just fine. In fact, there's an automated process that runs every day that will, over time, read just about all of the data in this table, and it hasn't reported a single error. Also if I run DBCC PAGE on one of the parent pages (which do exist, even though the "previous" pages don't), I can get the key columns, and I can SELECT all the data for all surrounding keys without any error.

Can anybody tell me what's going on here? Does it make sense for DBCC CHECKTABLE to be giving me these errors when the pages referred to don't even exist? Is it possible that CHECKTABLE itself is emitting spurious errors?