The goal of pkgdown is to make it easy for package developers to make elegant and useful packages websites. The defaults are tailored for smaller packages and for use on GitHub (particularly with new docs/ directory support), but it is flexible enough to be used as part of a bigger website. There are five parts to a pkgdown site:

  1. Home page
  2. Function reference
  3. Articles
  4. News
  5. Navbar

To build a pkgdown site, run build_site(). The function has some arguments (mostly to control where the output), but most of the configuration options are controlled by _pkgdown.yaml. These options include:

  • The site title, if different from the package name.

  • A path to a set of template, if you want to override the default page templates provided by the site.

  • A bootswatch theme name to easily tweak the overall appearance of the site.

Other options control the appearance of the other parts of the site.

Home page

The home page will be automatically generated from one of the following four files:

  1. index.Rmd
  3. README.Rmd

pkgdown tries them in order, which means that if you want different display for GitHub and pkgdown, you can have both and a

When including big graphics in the README, you may find it eaiser to use knitr::include_graphics("foo.png") combined with chunk option out.width = '100%'. This will make the graphic scale with the size of the page.


The function reference generates one page for each .Rd file in man/, placing the results in reference/. This is mostly a straightforward translation of Rd to HTML, along with evaluating the examples, and auto-linking function names to their documentation.

pkgdown will also generate an overall index, which by default, is just an alphabetically ordered list of functions. However, the index is better with human curation because functions can be grouped by function and described en masse. To override the defaults, provide a reference key in _pkgdown.yml:

  - title: "Connecting to Spark"
    desc: >
      Functions for installing Spark components and managing
      connections to Spark
      - spark_config
      - spark_connect
      - spark_disconnect
      - spark_install
      - spark_log
  - title: "Reading and Writing Data"
    desc: "Functions for reading and writing Spark DataFrames."
      - starts_with("spark_read")
      - starts_with("spark_write")
      - sdf-saveload

The reference should be an array of objects containing title, desc (description), and list of contents. Since common prefix and suffixes are often used for functional grouping, you can use the functions starts_with() and ends_with() to automatically include all functions with a common prefix or suffix. To match more complex patterns, use matches() with a regular expression.

The objects in reference can also contain a list of exclude, which allow you to exclude unwanted topics included via contents.

pkgdown will warn if you’ve forgotten to include any non-internal functions.


pkgdown will automatically build all .Rmd vignettes, including those in subdirectories, and render output to articles/. pkgdown will ignore the output format defined in the yaml header, and always use html_fragment(toc = TRUE, toc_float = TRUE).

If you want to include an article on the website, but not in the package (e.g. because it’s large), you can either place it in a subdirectory of vignettes/ or add to .Rbuildignore. As well, you must ensure that there is no vignettes: section in the article’s yaml header. In the extreme case where you want to produce only articles but not vignettes, you can add the complete vignettes/ directory to .Rbuildignore.

As with the function reference, articles will also get a default index, and it can be customised in a similar way (referring to file names rather than function names):

  - title: "Extend shiny"
    desc: >
      These packages provide advanced features that can enhance your Shiny 
    - shinydashboard
    - shinythemes
    - shinyjs
    - htmlwidgets


If is present, it will be parsed into pieces broken up by second level headings. These will be rendered to news/, with one page per minor release (so that 2.2.0, 2.2.1, and 2.2.2 are all described on a single page).

If you want more detailed release notes (aimed at teaching people about the new features), you could put these in (e.g.) vignettes/news and customise the navbar.