Canonical Tags in Http Headers: Set Preferred Urls for Pdfs and Non-html Resources

Canonical tags in HTTP headers give you a reliable way to declare the preferred URL for PDFs, downloadable files, feeds, APIs, images, and other resources that do not contain an HTML <head>. Used properly, they can reduce duplicate content SEO problems, clarify search intent, and help search engines consolidate ranking signals around the URL you actually want indexed.

This matters when several URLs expose the same document. A PDF might be available through a tracking URL, a print route, a category folder, a CDN hostname, and a product page download button. Without a clear preference, those versions can create search intent overlap or become part of a wider keyword cannibalization problem.

For publishers managing hundreds of pages and downloadable assets, the difficult part is rarely writing the header. The difficult part is deciding which URL should win, applying the rule consistently, and checking that the implementation survives redirects, caching, content negotiation, and future site changes.

What Is a Canonical Tag in an HTTP Header?

A canonical tag in an HTTP header is a Link response header that tells search engines which URL represents the preferred version of a resource.

The basic syntax is:

Link: <https://www.example.com/guides/technical-seo.pdf>; rel="canonical"

The header is sent with the server response rather than embedded in an HTML document. This makes it suitable for files that cannot carry an HTML canonical element, including:

PDF documents
Microsoft Word files
Excel spreadsheets
PowerPoint presentations
CSV files
XML feeds
JSON resources
Downloadable white papers
Non-HTML product manuals
Certain image or media responses

For an HTML page, the equivalent usually appears in the document <head>:

<link rel="canonical" href="https://www.example.com/guides/technical-seo/" />

For a PDF, that option is unavailable. You cannot reliably insert an HTML <link> element into a binary file and expect it to function as a canonical signal. The HTTP header is the appropriate implementation route.

The HTTP header format

A complete response may look like this:

HTTP/2 200
Content-Type: application/pdf
Content-Length: 248391
Link: <https://www.example.com/resources/seo-audit-checklist.pdf>; rel="canonical"

The URL inside angle brackets should be:

Absolute
Publicly accessible
The preferred version of the resource
Consistent with your HTTPS and hostname rules
Free from avoidable tracking parameters
A genuine equivalent or representative version of the returned file

The header does not redirect the user. It does not change the download destination. It simply suggests which URL should receive consolidated indexing signals.

That distinction is important. A canonical is a search engine signal, not a user-facing navigation instruction.

Why Canonical HTTP Headers Matter for PDFs and Non-HTML Files

PDFs often perform surprisingly well in organic search. They may rank for research terms, product searches, brand queries, and long-tail informational keywords. A single PDF can also exist at multiple locations because of publishing workflows, document management systems, campaign URLs, and ecommerce templates.

A typical example might include:

https://www.example.com/files/guide.pdf
https://www.example.com/download?file=guide.pdf
https://cdn.example.com/assets/guide.pdf
https://www.example.com/whitepapers/guide.pdf

If the versions contain the same material, search engines need a clear signal about which URL should be treated as the preferred source. The HTTP canonical header can help with that.

Common causes of non-HTML duplication

Duplicate or near-duplicate resources commonly appear because of:

URL parameters used for campaign tracking
Multiple download endpoints
HTTP and HTTPS versions
www and non-www hostnames
CDN and origin URLs
Printer-friendly document routes
Localised folders with identical content
Document migrations
CMS-generated attachment URLs
Uppercase and lowercase filename variations
Trailing slash inconsistencies
Archive pages exposing the same file
Product pages linked to old document locations
Session IDs or temporary download tokens

This whole thing can become difficult to see in a conventional crawl because many SEO crawlers prioritise HTML. A separate asset inventory is often needed.

Canonical Tags and Keyword Cannibalization

Keyword cannibalization occurs when multiple pages or resources on the same site appear to compete for the same query or closely related search intent. PDFs can contribute to that problem even when the SEO team is mainly looking at HTML URLs.

Suppose a company has:

A guide page targeting “technical SEO audit”
A PDF checklist targeting “technical SEO audit”
A webinar landing page using the same title
A downloadable report with nearly identical copy
A campaign page linking to a second copy of the report

These assets may create search intent overlap. The problem is not simply that five URLs contain the same phrase. It is that search engines may struggle to identify which resource best satisfies the query and which URL should accumulate authority.

A canonical header can help consolidate duplicate or substantially similar resources, but it does not automatically solve every cannibalization issue.

Canonicalisation is not consolidation in every case

A canonical is appropriate when the resources are duplicates or very close variants. It is not a substitute for a content architecture decision.

If a PDF serves a different purpose from an HTML guide, you may want both indexed. For example:

The HTML page provides an accessible explanation and interactive content.
The PDF is a printable compliance document used by professionals.
The HTML page targets “how to conduct a technical SEO audit”.
The PDF targets “technical SEO audit checklist PDF”.

Those pages may have related intent without being duplicates. Canonicalising the PDF to the HTML guide could remove a useful search result, depending on how search engines interpret the signals and the actual content relationship.

A keyword mapping strategy should decide whether the asset is:

A duplicate that should consolidate to another URL.
A supporting resource that should remain indexable.
A separate asset with a distinct search intent.
An outdated version that should redirect or be removed.
A low-value file that should not be discoverable through search.

How Search Engines Interpret an HTTP Canonical

A canonical HTTP header is generally treated as a hint rather than an absolute command. Search engines may choose a different canonical if the declared URL appears unsuitable, inaccessible, irrelevant, or inconsistent with stronger signals.

Google may compare the following:

The canonical HTTP header
Redirect destinations
Internal links
XML sitemaps
Content similarity
Page availability
Indexability directives
Structured data references
Site architecture
External links
Protocol and hostname consistency

The most reliable implementation is consistent across all of these signals.

Signals that should normally align

If your preferred PDF URL is:

https://www.example.com/resources/seo-guide.pdf

then ideally:

The PDF HTTP header points to that URL.
Internal links use that URL.
The XML sitemap includes that URL, if the file is intended for indexing.
Any HTML landing page references it consistently.
Redirects from old copies resolve to that location.
The preferred URL returns a successful response.
The URL is not blocked by robots.txt.
The document is not marked with a contradictory indexing directive.
The canonical is not itself a duplicate or redirecting URL.

A mismatch does not always cause an immediate failure. It does create uncertainty, which is exactly what technical SEO implementation should reduce.

When to Use a Canonical HTTP Header for a PDF

Use an HTTP canonical when the PDF should be associated with a preferred, indexable URL and one or more duplicate access paths exist.

Appropriate scenarios

1. Tracking parameters create duplicate download URLs

https://www.example.com/reports/market-study.pdf?utm_source=newsletter

The parameterised URL may return the same file as:

https://www.example.com/reports/market-study.pdf

The clean URL should usually be the canonical target.

2. A CMS generates several attachment paths

Some systems expose documents through both an attachment endpoint and a media directory:

https://www.example.com/?attachment_id=781
https://www.example.com/wp-content/uploads/2025/02/market-study.pdf

If the media URL is the preferred public address, the attachment response can point to it with a canonical header or redirect, depending on the user experience and system design.

3. A CDN exposes the same document as the origin

https://cdn.example.com/assets/manual.pdf
https://www.example.com/resources/manual.pdf

Cross-domain canonicalisation can be valid, but it requires careful control over caching and file availability. If users and search engines should only encounter the branded URL, a redirect or controlled CDN configuration may be cleaner.

4. An old document location remains live

If the old URL must stay available for business reasons but contains the same document, a canonical can communicate the preferred version. A permanent redirect is usually stronger where the old address has no continuing user value.

5. Multiple formats represent the same content

A report may exist as PDF, HTML and EPUB. These are not automatically duplicates in the strict technical sense because the formats differ, but if they deliver substantially the same content and you want one result to represent the set, a clear canonicalisation policy may be useful.

Treat this carefully. A PDF may satisfy a different user need from an HTML article.

When a Canonical Header Is the Wrong Solution

Canonicalisation cannot repair a fundamentally unclear URL strategy.

Do not use a canonical header as the primary solution when:

The old URL should permanently redirect.
The content is materially different.
The resource is obsolete and should return 410 Gone.
The file is private or should not be crawled.
The URL contains a temporary access token.
The preferred URL returns an error.
The resource has a different language or regional purpose.
You are trying to force unrelated content into one URL.
A page is competing because its topic and intent are poorly defined.

A canonical header also does not guarantee that a PDF will be indexed. It only helps establish a preferred relationship if the file is otherwise crawlable and valuable.

Canonical, redirect or noindex?

Situation	Recommended action
Exact duplicate with a useful old URL	301 redirect where practical
Exact duplicate that must remain accessible	HTTP canonical header
Outdated document with no replacement	`410 Gone` or controlled removal
Private or sensitive document	Access controls, not canonicalisation
Similar but independently useful resource	Keep separate and improve intent targeting
Low-value file that should not appear in search	Review `noindex` options and access controls
Duplicate parameter URL	Canonical, parameter handling, or redirect
Duplicate CDN copy	Canonical or architectural URL consolidation

The right decision depends on user access, link equity, business requirements, and whether the content has an independent reason to rank.

How to Implement a Canonical HTTP Header

The implementation depends on your server, CDN, application framework, and caching layer. Always test the final response from the public URL, not only the configuration file.

Apache `.htaccess`

For a known PDF filename:

<Files "seo-guide.pdf">
  Header set Link "<https://www.example.com/resources/seo-guide.pdf>; rel=\"canonical\""
</Files>

You may need the Apache mod_headers module enabled:

LoadModule headers_module modules/mod_headers.so

For a PDF directory, a pattern-based rule may be more suitable:

<FilesMatch "\.pdf$">
  Header set Link "<https://www.example.com/resources/seo-guide.pdf>; rel=\"canonical\""
</FilesMatch>

Do not use a single static canonical for every PDF in a directory. That would incorrectly tell search engines that every file is a duplicate of one document. Dynamic mapping is required when multiple PDFs each have their own preferred URL.

Nginx

A simple file-specific configuration may look like this:

location = /downloads/seo-guide.pdf {
    add_header Link '<https://www.example.com/resources/seo-guide.pdf>; rel="canonical"' always;
}

The always parameter helps send the header on responses beyond a standard successful response, although you should still avoid declaring canonical relationships on errors unless there is a specific reason.

For dynamically generated resources, application logic is often safer than broad Nginx rules. The application knows the document identity and can generate the correct URL.

PHP

<?php
header(
    'Link: <https://www.example.com/resources/seo-guide.pdf>; rel="canonical"',
    false
);
header('Content-Type: application/pdf');
readfile('/var/www/files/seo-guide.pdf');
?>

The false parameter allows PHP to replace rather than append the header depending on your implementation needs. Check the actual result because upstream servers can add or modify headers.

Node.js and Express

app.get('/downloads/seo-guide.pdf', (req, res) => {
  res.set(
    'Link',
    '<https://www.example.com/resources/seo-guide.pdf>; rel="canonical"'
  );
  res.type('application/pdf');
  res.sendFile('/var/www/files/seo-guide.pdf');
});

If query parameters are accepted, make sure the canonical URL is generated from a trusted document mapping rather than directly copying the requested URL.

Python and Django

from django.http import FileResponse

def seo_guide(request):
    response = FileResponse(
        open("/var/www/files/seo-guide.pdf", "rb"),
        content_type="application/pdf"
    )
    response["Link"] = (
        '<https://www.example.com/resources/seo-guide.pdf>; rel="canonical"'
    )
    return response

For larger systems, store canonical relationships in a document model. That provides an auditable source of truth when files are renamed or migrated.

Canonical Headers for JSON, XML, Feeds and Other Resources

The same pattern can apply to non-HTML resources beyond PDFs:

Link: <https://www.example.com/data/latest.xml>; rel="canonical"

For JSON:

Link: <https://api.example.com/v2/products>; rel="canonical"

The practical value varies by resource type and search engine support. XML feeds, APIs and private data endpoints are often not intended to rank, so canonicalisation may not be necessary. In those cases, access controls, authentication, robots.txt, or application architecture may be more relevant.

Images require particular care. If multiple URLs serve the same image, the best solution may involve consistent image URLs, redirects, sitemap inclusion, and clear page context. A canonical header should not be added mechanically to every file type without a defined indexing objective.

Important Rules for PDF Canonical URLs

Use the exact preferred URL

Choose one stable version:

Link: <https://www.example.com/resources/report.pdf>; rel="canonical"

Avoid pointing to:

http://www.example.com/resources/report.pdf
www.example.com/resources/report.pdf?source=download
https://www.example.com/resources/report.pdf/
https://www.example.com/resources/old-report.pdf

unless one of those is genuinely the preferred address.

Use absolute URLs

Absolute URLs reduce ambiguity across systems and crawlers. The header should include the protocol and full hostname.

Correct:

Link: <https://www.example.com/resources/report.pdf>; rel="canonical"

Less reliable for this use:

Link: </resources/report.pdf>; rel="canonical"

Avoid canonical chains

The requested file should not canonicalise to URL B when URL B canonicalises to URL C. Point the original response directly to the final preferred URL.

PDF A → Canonical C

is cleaner than:

PDF A → Canonical B → Canonical C

The same principle applies when the canonical URL redirects. You may not see an immediate issue, but it weakens the signal and complicates diagnosis.

Keep protocol and hostname consistent

If the site has moved to HTTPS, use HTTPS everywhere. Do not declare a non-secure canonical while internal links and redirects point to the secure version.

Do not canonicalise unrelated documents

A 2023 industry report and a 2025 report may share a topic and target phrase, but they are not duplicates. Combining them through canonicalisation could remove a legitimate historical resource from search.

Be cautious with cross-domain canonicals

Cross-domain canonicalisation may be appropriate for syndicated documents or an asset hosted on a central publishing platform. It can also create problems if the target domain changes, becomes inaccessible, or does not clearly represent the same content.

Record ownership, approval and expiry conditions for cross-domain relationships. This is basic governance, but it gets missed.

HTTP Canonical Headers and Content Negotiation

Content negotiation can create technically complex duplication.

A single URL might return:

HTML to a browser
PDF to a user with a format parameter
JSON to an API client
Different language content based on the Accept-Language header

If the response changes according to request headers, caching and canonicalisation need to be coordinated. Use the Vary response header where appropriate:

Vary: Accept, Accept-Language

A canonical should describe the specific representation and preferred URL policy. If the same URL returns different content types, test each response independently.

For example:

https://www.example.com/report
https://www.example.com/report?format=pdf
https://www.example.com/report.pdf

These may not be equivalent from a search engine’s perspective. Decide whether the HTML version, PDF version or both should be available as search results. Then make the relationship explicit through links, redirects, canonical headers and content structure.

Auditing Canonical Headers as Part of a Keyword Cannibalization Audit

A keyword cannibalization audit that checks only HTML canonical elements is incomplete. Your crawl should include downloadable resources and important non-HTML endpoints.

Step 1: Build a complete asset inventory

Collect URLs from:

XML sitemaps
Internal links
CMS media libraries
Server logs
CDN reports
Google Search Console
Analytics landing pages
Backlink tools
Document management platforms
Product feeds

Record the file type, status code, content length, last modified date and source location.

Step 2: Group likely duplicates

Use filenames, hashes and content similarity to identify groups:

Group	URL	File type	Content hash	Status	Canonical
A	`/files/guide.pdf`	PDF	`8af31`	200	HTML
A	`/download?id=82`	PDF	`8af31`	200	None
A	`/assets/guide.pdf`	PDF	`8af31`	200	PDF
B	`/reports/2024.pdf`	PDF	`c4129`	200	None

A matching hash strongly suggests identical binary files, though metadata changes can produce different hashes for visually identical documents. Text extraction and page rendering may be necessary for more advanced comparisons.

Step 3: Map search intent

For each asset, ask:

What query could this resource satisfy?
Is that query informational, commercial, navigational or transactional?
Does an HTML page already target the same intent?
Is the PDF a supporting document or the main answer?
Does the file attract impressions or backlinks?
Would consolidation improve relevance or remove useful visibility?

This is where the keyword mapping strategy becomes more valuable than a simple URL list.

Step 4: Select the preferred URL

Apply a practical scoring model:

Criterion	Score range
Content completeness	0 to 5
Internal link prominence	0 to 5
External authority	0 to 5
User experience	0 to 5
Search intent alignment	0 to 5
Stability and maintainability	0 to 5

The highest-scoring URL is not automatically the winner. Business requirements and accessibility still matter. The rubric simply makes the decision less subjective.

Step 5: Implement and test

After implementation, verify:

Status code
Final URL after redirects
Content-Type
Link header
Cache behaviour
Canonical target availability
Internal links
Sitemap status
Search Console indexing signals

Use command-line testing:

curl -I https://www.example.com/downloads/seo-guide.pdf

Expected output may include:

HTTP/2 200
content-type: application/pdf
link: <https://www.example.com/resources/seo-guide.pdf>; rel="canonical"

Test with and without query parameters:

curl -I "https://www.example.com/downloads/seo-guide.pdf?utm_source=email"

The header should still point to the clean preferred URL if that is your policy.

A Practical Example: Consolidating Competing PDF URLs

Imagine a software company publishes a technical audit checklist. It has accumulated four URLs:

https://www.example.com/checklist.pdf
https://www.example.com/downloads/technical-audit-checklist.pdf
https://www.example.com/resources/technical-audit-checklist.pdf
https://cdn.example.com/checklist.pdf

All four files contain the same 18-page document. The resource URL receives the strongest internal links and appears in the XML sitemap, so the team chooses it as canonical.

The preferred header becomes:

Link: <https://www.example.com/resources/technical-audit-checklist.pdf>; rel="canonical"

The team then takes these actions:

Redirects the first URL to the preferred resource URL.
Adds the HTTP canonical header to the CDN response.
Updates internal links to use the preferred URL.
Removes tracking parameters from permanent document links.
Keeps campaign URLs functional but canonicalised.
Checks that the target returns 200 OK.
Reviews impressions for competing versions after recrawling.

This approach helps consolidate competing pages and files without disrupting campaign measurement. The campaign platform should measure the referrer or campaign data, not create a new permanent document identity every time.

Common Implementation Errors

Putting an HTML canonical inside a PDF

A PDF does not have a normal HTML <head>. Adding visible text or metadata that resembles a canonical element will not provide the same signal.

Use the HTTP Link header.

Canonicalising every PDF to the homepage

This is a blunt configuration mistake. A document should point to its own preferred equivalent or to a genuinely representative HTML page, not automatically to the homepage.

Returning a canonical target with a 404

Search engines cannot consolidate signals effectively towards a missing destination. Monitor canonical targets as part of your regular technical SEO checks.

Using relative URLs

Relative URLs can be misinterpreted by tools and are less explicit in complex environments. Use absolute URLs.

Adding conflicting headers

A CDN may add one canonical while the application adds another:

Link: <https://www.example.com/a.pdf>; rel="canonical"
Link: <https://www.example.com/b.pdf>; rel="canonical"

Multiple conflicting canonical values create uncertainty. Inspect the final response as received by a crawler.

Forgetting cache variation

If a dynamic response generates different canonical headers based on the requested parameter but the cache stores only one version, users and crawlers may receive the wrong header. Review cache keys and surrogate rules.

Canonicalising substantially different language versions

A French PDF and an English PDF may have equivalent intent but different audiences. Canonicalisation alone is not a replacement for international targeting. Use appropriate language architecture and link relationships for the page types involved.

Measuring Whether Canonicalisation Worked

Canonical implementation should be evaluated with measurable indicators rather than a single inspection.

Track:

Number of duplicate PDF URLs indexed
Impressions by duplicate URL
Clicks to preferred URLs
Canonical selection reported in Search Console
Crawl requests to parameterised versions
Organic traffic to old document URLs
Backlinks consolidated to the preferred address
Number of competing URLs per keyword cluster
Internal links using non-preferred variants
Server responses with missing or conflicting headers

A useful before-and-after comparison might look like this:

KPI	Before	After	Interpretation
Indexed duplicate PDF URLs	14	3	Consolidation is progressing
Preferred URL impressions	1,800	2,650	Visibility has moved towards the target
Parameter URL crawls	9,400	4,100	Crawl waste may be reducing
Missing canonical headers	38%	4%	Deployment coverage improved
Competing URLs for target cluster	6	2	Search intent overlap is clearer

Do not assume a canonical change will produce an immediate ranking increase. Search engines need to recrawl and reassess the resources, and other issues may be affecting performance at the same time.

The more useful question is whether signals, visibility and indexing are becoming more concentrated around the URL that best serves users.

How SEOLetters Supports Technical SEO Publishing Workflows

Canonical header work is usually part of a wider content and information architecture project. You need to identify the topics being targeted, map existing assets, find site gaps, and decide whether to refresh, consolidate or create new content.

SEOLetters is built for publishers who need that workflow to run repeatedly. It can research keywords, identify difficulty levels, create topical authority clusters and generate structured articles with headings, internal links, schema and images in a brand-aware voice.

That is useful when a keyword cannibalization audit reveals that the site has several weak pages competing for one intent. You can use the platform to plan the replacement article, build the supporting cluster and publish through WordPress, Shopify or a webhook while the technical team manages redirects and canonical headers.

A repeatable workflow with SEOLetters

Research the keyword group: Identify search intent overlap, related queries and difficulty.
Audit existing coverage: Compare articles, PDFs, category pages and product resources.
Choose the primary URL: Decide which resource should own the topic.
Consolidate competing pages: Redirect, canonicalise, refresh or remove assets as appropriate.
Create supporting content: Build related pages that answer distinct subtopics.
Publish consistently: Connect the destination and use an appropriate campaign cadence.
Measure performance: Review rankings, clicks, impressions and content decay.
Refresh existing assets: Update old pages and documents rather than producing unnecessary duplicates.

The platform supports multiple AI providers, including Gemini, OpenAI and Claude, and allows you to bring your own keys. Its campaign scheduler can research, write and publish on a recurring schedule, while refresh campaigns help maintain existing pages.

It also supports generation across 21 languages, product-aware articles for affiliate and ecommerce publishing, and performance reporting for published content. If you want to inspect the workflow, visit the SEOLetters app and review how it can fit into your editorial operation.

Canonical Headers in Large-Scale Publishing Operations

At enterprise scale, canonicalisation should be treated as a data problem as much as a server configuration problem. Store each resource’s preferred URL, status, language, owner, last review date and consolidation decision in a central system.

A simple governance record can include:

Field	Example
Asset ID	PDF-00482
Current URL	`/downloads/audit-checklist.pdf`
Preferred URL	`/resources/technical-audit-checklist.pdf`
Content type	`application/pdf`
Primary intent	Technical SEO checklist
Duplicate group	TG-019
Action	HTTP canonical plus redirect
Owner	Organic search team
Review date	1 September 2025
Business status	Active

This prevents a common failure pattern where the content team updates a document, the development team changes its location, and the SEO team continues referencing an address that no longer exists.

For sites publishing at scale, automation should validate:

Every indexable PDF has a documented canonical policy.
Every canonical target returns a successful response.
No canonical target points to a redirect chain.
Duplicate files are grouped by content identity.
Old URLs have a defined redirect or retirement status.
New campaign assets do not create uncontrolled duplicates.
Internal links favour preferred versions.

SEOLetters can help organise the content planning and publishing side of this process. The technical governance still needs an SEO, developer or platform owner who understands the delivery stack.

Key Takeaways for PDFs and Non-HTML Resources

Canonical tags in HTTP headers are useful when you need to declare a preferred URL for files that cannot carry an HTML canonical element.

The most important principles are:

Use the Link response header with rel="canonical".
Point to one absolute, stable and indexable URL.
Keep redirects, internal links, sitemaps and canonicals aligned.
Include PDFs in your keyword cannibalization audit.
Do not canonicalise genuinely different resources just because they share a keyword.
Use redirects when an old URL no longer needs to remain accessible.
Check CDN, application and cache behaviour together.
Monitor indexing and visibility after implementation.
Build a keyword mapping strategy before consolidating competing pages.
Treat technical canonicalisation as part of a wider publishing workflow.

A canonical header will not fix unclear search intent, thin content or poor site architecture by itself. It can, though, remove an important source of ambiguity when several URLs expose the same non-HTML resource.

Final Checklist: Canonical HTTP Headers for PDFs

Before deployment, confirm the following:

The PDF or non-HTML resource has a clear preferred URL.
The Link header uses valid syntax.
The canonical URL is absolute and uses HTTPS.
The target returns 200 OK.
The target contains equivalent or representative content.
No conflicting canonical headers are present.
Redirects do not create a canonical chain.
Internal links use the preferred URL.
Sitemap inclusion matches the indexing strategy.
Query parameters do not create accidental canonical variants.
CDN caches return the correct header.
Old files have a documented redirect, canonical or retirement action.
The asset has been reviewed for search intent overlap.
Performance monitoring is in place.

If you’re dealing with a growing library of PDFs, guides and downloadable assets, the work becomes easier when technical decisions and content planning sit in the same operating process. Use SEOLetters to build the keyword map, identify content gaps, plan topical authority clusters and publish the pages that support your preferred resources.

For implementation questions, workflow requirements or a more advanced publishing setup, the rightbar is the contact path.