PDF or WordPress Page? How E-commerce and Service Brands Should Publish Pricing and Product Catalogs to Get Found by Search Engines and Cited by AI

TL;DR Google and Bing do index PDFs, but HTML wins wherever pricing and catalog visibility actually matter. Structured data (Product, Offer, PriceSpecification, FAQPage) only works on HTML pages, so a PDF can never carry it. Mobile-first indexing and Core Web Vitals apply to HTML only. AI crawlers like OAI-SearchBot, PerplexityBot, and Google-Extended are built around fetching HTML pages. The simple rule: HTML is your discoverable surface, PDF is your downloadable file. Honest note: no study isolates HTML vs PDF citation share in AI answers, so ignore anyone quoting a percentage.

PDF or WordPress page for pricing — the short answer

If you sell something and you want people to find your prices, put them on an HTML page in WordPress. Keep the PDF as a download for the people who need a file.

That is the whole answer, and here is why it holds up. Three things decide whether your prices get seen: structured data, mobile rendering, and how AI crawlers read your site. PDFs lose on all three.

Let's take the questions people ask most.

Does Google index PDFs? Yes. Google treats PDF as an "encoded file type" that needs a specific parser. So a PDF can show up in search. But indexing is not the same as competing well. Government guidance from Digital.gov is blunt about it: PDFs "often fall lower in the ranking algorithm" than HTML pages.

Can a PDF carry schema markup? No. Product, Offer, PriceSpecification, FAQPage, and Organization markup are documented for web pages. You cannot embed JSON-LD inside a PDF. That single fact keeps PDFs out of rich results and shopping surfaces.

Do AI tools read PDFs? They can fetch them, but they are harder to pull clean text and price signals from. AI crawlers are built around retrieving pages, not parsing static documents. So a PDF is not invisible to AI. It is just harder to extract and harder to cite.

One thing to be careful about: don't let anyone tell you PDFs are dead or that AI ignores them completely. That is not true. The honest framing is that PDFs are a weaker surface for prices and catalogs, and a fine format for documents.

Who this guide is for (and when a PDF is still the right call)

This guide is for e-commerce owners, marketers, and service brands who publish prices or a product catalog and are deciding between a PDF and a WordPress page. It assumes you have a website, you control what gets published, and your prices change from time to time.

If that sounds like you, HTML should be your default. But PDFs are not useless. There are real cases where a PDF is the right format, and you should not force those into a web page.

When HTML is the right call:

• You publish prices, packages, or a product catalog.
• Your prices or availability change.
• You want your products to appear in rich results or shopping surfaces.
• You want AI tools to be able to quote your prices accurately.
• You serve multiple currencies or regions.

When PDF plus an HTML page is the right call:

• B2B spec sheets that buyers print or attach to internal documents.
• Regulated documents like safety data sheets or compliance files.
• Certificates, warranties, and signed contracts.
• Anything where print fidelity or a fixed version matters.

Notice the pattern: PDF is for documents, HTML is for discovery. When you need both, publish both, and link them together.

What you need before you start

Before you touch anything, gather these. It saves you a second round of work later.

• Access to your WordPress admin, or a developer who has it.
• A clean list of your products or services with price, currency, and availability.
• Product identifiers where you have them: GTIN, MPN, or SKU.
• One person who owns price updates. Not a team, one name.
• Access to your robots.txt file and your SEO plugin or panel.
• Your current PDFs, if you already have them, so you can decide what stays.
• A short list of the questions customers ask about pricing, shipping, and returns.
• A way to check your page source, so you can confirm prices are visible without JavaScript.

If you do not have GTINs, that is fine. Use SKU or MPN instead. The goal is to give search engines and AI tools a consistent way to identify what you sell.

Step 1 — Decide what belongs on the page and what stays a download

This step is about drawing a clean line. Some content belongs in HTML, some belongs in a file. Mixing them up is where most pricing problems start.

Here is a simple way to sort it.

A few practical notes. Put the link to any PDF on the relevant HTML page, not buried in a footer. And think about whether that PDF should be indexed at all. If it is just a duplicate of your HTML prices, letting it compete in search usually does not help you.

Step 2 — Build the pricing page in WordPress

Now let's build the page. Keep it simple and readable.

1. Give pricing its own URL. Something like /pricing or /catalog. Do not hide prices inside a blog post or a contact page.
2. Render prices on the server. The price text should be in the page source, not injected later by JavaScript. If you view the source and see the numbers, you are good.
3. Use one URL per currency or region. Google's own guidance is to have a distinct URL per currency. A single page trying to serve every region gets messy fast.
4. Build a clear price table. Product name, price, currency, and availability. Keep it scannable.
5. Show the last updated date. A visible date tells both people and machines that the page is current.

Checkpoint: open your page, right-click, and view the source. If you can see your prices in the raw HTML, you have passed the most important test.

Why does JavaScript matter so much here? Because Google warns that Product markup generated by JavaScript "can make Shopping crawls less frequent and less reliable." Server-rendered prices avoid that whole problem.

Step 3 — Add structured data (Product, Offer, PriceSpecification, FAQPage)

Structured data is how you tell machines what your prices mean. It goes in the HTML as JSON-LD, and it is the part a PDF can never do.

Here are the fields worth filling in:

• Product: name, description, image, brand, SKU or MPN or GTIN.
• Offer: price, priceCurrency, availability, URL, seller.
• PriceSpecification: use this for different price types, like the active price, a strikethrough price, or a member price.
• FAQPage: mark up your pricing, shipping, and returns questions.
• Organization: use this for return and refund policies.

Two things to watch. First, merchant listings expect a price greater than zero, so do not mark up "contact us for pricing" as a price. Second, keep the markup in the initial HTML. If your plugin injects it with JavaScript after load, crawlers may miss it or read it less reliably.

If you are not sure your markup is valid, test it before you publish. A broken snippet is worse than no snippet.

Step 4 — Make the catalog crawlable and citable by AI

This is where Google visibility and AI visibility meet. The good news is that the work overlaps a lot.

Start with your robots.txt. These crawlers should be allowed:

• OAI-SearchBot: indexes pages for ChatGPT search. Block it and your site will not show up in ChatGPT search answers.
• PerplexityBot: surfaces and links websites in Perplexity results. It is not used for training foundation models.
• Google-Extended: controls training and grounding for Gemini and Vertex. Worth knowing: it is not a ranking signal and does not affect your inclusion in Google Search.

Robots.txt changes usually take around 24 hours to propagate, so give it a day before you judge the results.

Next, make sure your content is readable without running JavaScript. If your catalog only appears after scripts load, crawlers may see an empty page.

Then keep things consistent. Your product names, categories, descriptions, and prices should match across your pages, your feed, and any PDFs you keep. Contradictions confuse both search engines and AI tools.

Finally, keep it fresh. Stale prices are one of the fastest ways to lose trust with both people and machines.

A quick word on llms.txt. It gets a lot of attention, but adoption is low and there is no confirmed impact on citations yet. Treat it as an experiment, not a guaranteed lever.

Step 5 — If you must keep a PDF, do this

Sometimes a PDF is non-negotiable. That is fine. Just make it work as hard as it can.

• Treat the PDF as an add-on to an HTML page, never as a replacement.
• Use a descriptive file name, like acme-industrial-pumps-price-list-2026.pdf.
• Fill in the metadata: a real title, a description, and the document language.
• Make sure the text is selectable. If it is a scan, run OCR so the words are readable.
• Link to it from the HTML page with clear anchor text.
• Keep the HTML page as the primary source for prices and availability.
• Update the PDF whenever prices change, or note clearly that the HTML page is the current version.

One common worry: does having both a PDF and an HTML page create duplicate content? Not in the way people fear. Google has said the two are not treated as duplicates, both can be indexed, and they can compete. The HTML page usually wins because it is better connected to the rest of your site.

Common mistakes and how to fix them

• Prices only in a PDF. Fix: publish an HTML pricing page and keep the PDF as a download.
• Prices injected by JavaScript. Fix: server-render the prices so they appear in the page source.
• One PDF for every currency. Fix: create a separate HTML URL per currency or region.
• Catalog locked behind a login. Fix: keep a public HTML layer with the indexable price and availability signals.
• Prices that never get updated. Fix: assign one owner and set a review schedule.
• AI crawlers blocked in robots.txt. Fix: allow OAI-SearchBot, PerplexityBot, and Google-Extended.
• No structured data at all. Fix: add Product, Offer, PriceSpecification, and FAQPage markup in JSON-LD.

FAQ

Does Google index PDF files? Yes. Google can index PDFs as encoded file types. But they tend to rank lower than HTML pages and cannot carry structured data.

Can a PDF have schema markup? No. Product, Offer, PriceSpecification, and FAQPage markup are documented for web pages. There is no way to embed JSON-LD inside a PDF.

Do AI chatbots read PDFs? They can fetch them, but PDFs are harder to extract clean text and price signals from. AI crawlers are built around retrieving HTML pages, so HTML is the more reliable surface.

Is a PDF and an HTML page duplicate content? No. Google has said the two are not treated as duplicates, both can be indexed, and they can compete. The HTML page usually performs better because it is better linked.

What to do next

Here is a sensible order of work: build the HTML pricing page first, add structured data second, set up a product feed third, and start monitoring fourth. Doing it in that order means each step builds on the last.

A quick decision tree:

• Publishing prices or a catalog that changes? Go HTML only.
• Need a printable or signable document too? Go HTML plus PDF, with the PDF linked from the page.
• Running a large catalog across channels? Go feed plus HTML, so your data stays consistent everywhere.

Then measure. Watch whether your pages show up for pricing queries, whether AI tools mention your brand and products, and whether the traffic you get actually converts. If something is off, check the basics first: are prices in the source, is the markup valid, are crawlers allowed.

This is also where Semly fits in naturally. Once your HTML pricing page and structured data are live, Semly helps you see how your brand actually shows up in AI answers. It monitors prompts, sources, competitors, and responses across models like ChatGPT, Gemini, Perplexity, and Claude, and it helps you build data that LLMs can read, including feeds, JSON-LD, and a knowledge base. You can start with a free AI visibility report at report.semly.ai to see where you stand.

The short version: publish prices where machines can read them, keep PDFs for the documents that need them, and then keep an eye on how AI talks about you. That combination is what gets you found and, over time, cited.