What is a PDF? Uses, and PDFs on your website: indexing and tracking

PDF stands for Portable Document Format, a file format developed by Adobe, now an open standard under ISO 32000, that preserves a document’s fixed layoutFixed layoutFonts, page elements, and images retain their positions and sizes across devices and applications. across devices.

For website documents, we choose HTML for reading online and PDF for downloading and keeping. We assess search visibility, mobile reading, accessibility, speed, and tracking together.

What does PDF stand for?

PDF stands for Portable Document Format. The format preserves document layout; .pdf is the extension at the end of the filename.

Using the format and reading PDFs is free. Editors have free and paid versions; any charge relates to the software.

We distinguish three situations:

1. The question concerns the file format → we explain its uses, then decide whether website visitors need to read the content online or download it.
2. PDF appears in another field → we check the context: in statistics, PDF means probability density function. A report delivered as a PDF still refers to the file format.
3. A document must be sent as a PDF → we select PDF when saving from Word. Other applications offer Microsoft Print to PDF on Windows or Save as PDF in the Mac print dialog. We reopen the file to check its layout.

What are PDFs used for?

PDFs preserve layout when sharing invoices, contracts, proposals, catalogs, price lists, ebooks, and official correspondence.

Text, images, headings, tables, and signature fields keep their positions when printed. Browsers open PDFs without separate software; phones use Files on iPhone or Google Drive or a browser on Android. Word documents can shift between applications, so we use Word for editing and PDF for sharing and printing.

We export the final version and retain the editable source. PDF was not designed for text editing, but PDF editors can change the document. A digital signature indicates changes after signing. Saving as PDF does not sign it.

Should a website use PDF or HTML?

We use HTML for reading online and PDF for downloading, keeping, or printing. HTML structures web pages: text fits the screen, with navigation and related links available.

The document’s purpose determines our approach:

1. A catalog, price list, or brochure → we keep the PDF and create an HTML summary with product and pricing headings, linking to the complete download.
2. An article, guide, or manual → we use HTML. PDFs are indexable but lack the website’s navigation, page tracking, and comfortable mobile reading.
3. A form needs completing → we build an HTML form, avoiding the extra download, completion, and return steps. If a signed printout is needed, we generate a PDF from the completed form.

We make this choice when mapping website content. The summary explains the document’s subject and intended audience before visitors decide to download it.

Can Google index PDFs?

Google can index PDFs, read their text, follow their links, and display a PDF label in search results. Google Search Central lists PDF as an indexable format; uploading alone does not guarantee indexing.

Google’s PDF FAQ explains that search titles draw on Title metadata and incoming link text. We therefore supply both. It also states that embedded images are not indexed. PDFs support links and heading tags, but do not carry the website’s menu, HTML H1/H2 structure, structured data, or GA4 code in the same way.

Our publishing checks follow this order:

1. FilenameWe choose a short, descriptive, hyphenated name: urun-katalogu.pdf means “product catalog.”
2. Title metadataWe fill in the Title field in Word’s document properties or Acrobat’s document description, and name the subject clearly in the download link.
3. HTML summaryWe publish a heading, explanatory paragraphs, and download link, then direct internal links to this page.
4. File sizeWe compress images and enable Fast Web View.
5. IndexingFor PDFs that should stay out of search, we send noindex in the X-Robots-Tag HTTP header, allowing crawling so Google can read it.

Why do PDFs pose mobile and accessibility problems?

A PDF’s fixed layout does not reflow to fit the screen, and untagged PDFs lack the structure screen readers need. Phone readers must zoom and scroll; we use HTML for longer reading.

Accessible PDFs use tags to identify headings, paragraphs, and reading order. PDF/UA is the accessibility standard defined by ISO 14289; tags alone do not establish compliance. When exporting from Word, we enable document structure tags in the PDF export options.

We assess three possibilities:

1. The PDF is a scanned image → we add selectable text with OCR or regenerate it from the source, checking text and reading order.
2. The PDF is digital but untagged → we correct heading tags, reading order, and image alternative text.
3. The PDF is tagged with its language defined → we run accessibility checks, then verify file size and Fast Web View before publishing.

Google’s PDF FAQ describes extracting image-based text with OCR. We prepare the document’s own text layer rather than rely on that for accessibility. Compression reduces image weight; Fast Web View lets supported readers display the first page before the whole file downloads. Large embedded documents also affect page loading, so we review media and document sizes together.

How do GA4 and Search Console measure PDFs?

GA4’s enhanced measurement records download-link clicks through file_download; Search Console reports a PDF URL’s search visibility.

Google’s GA4 documentation states that clicking a .pdf link triggers file_download when the site has a GA4 tag and file download measurement enabled. It proves neither a completed download nor reading.

The file_name parameter identifies the document; link_text identifies the clicked button. In GA4’s Admin area, we create katalog_indirme (“catalog download”) for events where event_name equals file_download and file_name contains katalog. We mark only that derived event as a key event, so we do not treat every file click as the same business goal.

GA4 code does not run inside PDFs, so this setup cannot measure subsequent reading. In Search Console’s performance report, we filter page URLs containing .pdf and review clicks and impressions. A visit from search directly to a PDF does not trigger the HTML page’s download event.

Our observation: a PDF click does not reveal the reader’s next step. An HTML summary provides links and a measurable route through the site.

What are common website PDF mistakes?

The most common mistake is hiding explanatory content inside a PDF while leaving its web page empty. We correct these issues before publishing:

• An empty download page: We explain the document’s subject and scope.
• Scanned pages: We add a text layer and check accessibility tags and reading order.
• Missing Title or vague filename: We supply a title and descriptive filename.
• Copies at different URLs: We select the current file URL and align links and canonical preferences.
• Uncompressed images: We reduce size while preserving readability and check opening on phones.
• Untracked PDFs opening in new windows: We verify that source-page clicks generate file_download; a new window does not establish tracking.

We start with a Google search for site:markention.com filetype:pdf, list visible PDFs, and flag those without summary pages. We plan HTML for reading alongside PDFs for keeping; related guidance appears on our English blog.

Frequently asked questions