
Restoring ?p=1 and ?id=42 URLs - why almost every tool gives up, and how I don't
Parametric URLs are the catalog. Generic scrapers pretend they do not exist. Why they vanish, and the capture that puts them back as WordPress pages.
By Dmitriy Gabdrakhmanov. Operator, WPSERVICE LAB.
A sentence I have heard from five agencies, almost word for word:
“The catalog used ?id= URLs everywhere. Every other service said those pages were lost.”
They were not lost. They were ignored. There is a big difference, and it is the single most common reason a “restored” site turns out to be missing the catalog and listing pages.
What is a parametric URL, and why does it matter?
A parametric URL is any address that uses a query string to load different content from the same path:
example.com/blog/?p=42- classic WordPress post IDexample.com/product.php?id=17- old PHP catalogexample.com/page.php?cat=3&page=2- paginated listingsexample.com/?s=shoes- search results
For an e-commerce site, a directory, a forum, or an old WordPress blog, these URLs are the bulk of the real content. The homepage is decoration. The ?id= pages are the product catalog, the article archive, the member profiles - the stuff someone would actually want to recover.
Why most tools skip them
Generic archive scrapers work by following links from the homepage. They hit /about, /contact, /blog, and stop. When they encounter ?p=42, three things go wrong:
1. The crawler treats query strings as duplicates
Standard crawling logic collapses /blog/?p=1, /blog/?p=2, and /blog/?p=3 into a single “page” because the path is identical. Only the first one gets saved. The rest vanish - even though they are entirely different articles.
2. The Wayback snapshot for that exact URL may be missing
Even if a tool tries to fetch ?p=42, the Internet Archive may not have captured that exact query string. It captured ?p=41 and ?p=43 on different days. Naive tools report “not found” and move on. A real recovery has to find the closest snapshot per URL, not the closest snapshot overall.
3. WordPress does not store them as pages by default
When you import the recovered HTML into WordPress, a ?p=42 address is not a page - it is a query against the post table. Dumping the HTML into a page does not restore the URL. You need rewrite rules, custom routing, or - my preferred approach - to materialize each parametric URL as a real, editable WordPress page that preserves the original address via a redirect map.
How I recover parametric URLs end-to-end
I built a capture pipeline specifically for this. It does three things a generic scraper does not:
- Discovers the parameter space. It reads the archive’s own link graph for your domain and extracts every
?p=,?id=,?cat=value it can find - including values only referenced from other archived pages. - Fetches per-URL snapshots. For each discovered parameter, it queries the Wayback CDX API for the best available capture date and downloads that exact URL - not a collapsed “representative” of the path.
- Materializes each as a distinct WordPress page. Each parametric URL becomes its own editable page in WordPress, with the original address preserved through a 301 redirect map so existing links hit the new pages.
The result: a catalog that had 1,800 ?id= product pages in 2019 has 1,800 product pages in the restored WordPress today - not 1,800 lines in a CSV, not 1,800 broken links, but 1,800 pages you can open in the editor.
Why this changes the economics
Most budget restoration pricing is built around “pages” meaning “top-level navigation pages.” A 50-page site for $15 sounds fine until you realize your real site was 2,000 parametric pages and the seller’s definition of “page” quietly excluded all of them. You pay $15, get a homepage and four nav links, and then get quoted $400 to recover “the rest.”
I price by total recovered page count, up front, after I see the archive. Fixed price. No surprise add-ons. Send the domain list on Telegram @wpservicelab and I will tell you what is actually in the snapshots - not the optimistic version a $15 gig quotes you.
How to tell if your site has parametric URLs at risk
Before you commission a restore, paste your old URLs into the Wayback Machine and check a few of these:
- If your old site was WordPress, look for
/?p=NUMBERin archived links - those are post IDs. - If it was a catalog or shop, look for
?id=,?product=,?item=. - If it was a forum, look for
?thread=,?t=,?f=. - Open the archived homepage, view source, and search for
?inhrefattributes. Every match is a parametric URL that needs dedicated recovery.
If you find more than a handful of ?p= / ?id= URLs, send the list on Telegram @wpservicelab. I will tell you how many are recoverable from the archive and what the scope is.
Send a domain and a Wayback link
Same restore if you bought a drop. Packs if you have a list. Scope and price before any work starts.
Restore scope and packs