# blogdown for R Markdown Websites

> blogdown is an R package for building blogs and websites with R Markdown, Hugo, and other supported static site generators. It fits technical publishers who want executable analysis, generated graphics, citations, footnotes, LaTeX math, and HTML widgets in site content.

**rstudio/blogdown** — Create Blogs and Websites with R Markdown

- Repository: https://github.com/rstudio/blogdown
- Website: https://pkgs.rstudio.com/blogdown/
- Stars: 1,793 · Forks: 324
- Language: R
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/rstudio-blogdown

## What blogdown is built to publish

blogdown addresses a specific publishing problem: how can a technical author use R Markdown as a website output format while keeping executable analysis close to the prose that explains it? The package is aimed at people publishing blogs, documentation, data science material, statistics content, data visualization, programming articles, or educational websites. Its usefulness comes from the combination of an R Markdown workflow with a static website generator rather than from a generic collection of page templates.

The content model includes R code, or code in other languages supported by knitr. When the site is built, blogdown can produce rendered graphics, tables, analysis results, and HTML widgets. Technical writing features are also available through bookdown, including citations, footnotes, and LaTeX math. That combination makes blogdown relevant to a reproducible technical site more than to a conventional hand-written blog that contains no computational material.

The package is not limited to posts arranged in a flat directory. The README specifically identifies subdirectory organization as a difference from other R Markdown-based websites. That layout can support broader sites with separate sections or content types. It does not mean that blogdown is a complete site design system. The README points users to Hugo themes and to adding pages or posts after the first site is created, so appearance and information architecture remain partly under the site's maintainer's control.

## The R Markdown, Hugo, and browser workflow

Hugo is the default static website generator used by blogdown. Jekyll and Hexo are also supported, but the documented workflow is centered on Hugo. An R Markdown document can contain executable code and generated output, while Hugo builds the site's content into static files. blogdown connects those stages through functions that create a site, serve it locally, rebuild it after edits, and refresh the browser.

The most direct development loop is `blogdown::serve_site()`. According to the README, it builds the website, loads it into a web browser, and automatically refreshes the browser when Markdown or R Markdown files are updated. This matters because the preview is not merely a file watcher around a static Markdown site. It is intended to support the R Markdown source files that define a blogdown site.

The README draws a precise boundary around the command line alternative. It says not to use `hugo server` to build or serve the site because that command understands plain Markdown files and cannot build R Markdown. In practical terms, replacing blogdown's serving function with a raw Hugo command can omit the R Markdown rendering stage. The package therefore acts as an orchestration layer between content authoring, code execution, site generation, and previewing.

## Installing blogdown and creating the first site

The README gives a CRAN installation command for the released package. This is the appropriate starting point when the reader wants the package documented by its public installation path.

```r
install.packages('blogdown')
```

After installation, create the site under an empty directory. The following call creates the site skeleton, downloads a Hugo theme from GitHub, adds sample content, opens a browser, and opens `hello-world.Rmd` automatically. The empty-directory requirement prevents the function from mixing its generated structure with existing files.

```r
blogdown::new_site()
```

The reader should see a new site in the browser and be able to edit the sample `hello-world.Rmd` file. Saving that file causes the website to be rebuilt and the page to refresh, according to the README. That is the first complete loop to verify: installation, site creation, sample post editing, rebuild, and browser refresh.

For an RStudio workflow, the README also documents `File -> New Project -> New Directory -> Website using blogdown`. This menu route is preferable when the reader already works in RStudio because it creates the expected project setup. Developers who need the repository version can install it through remotes, but that is a separate installation choice.

```r
remotes::install_github('rstudio/blogdown')
```

## Choosing themes, content, and generator boundaries

The default site created by `blogdown::new_site()` is a starting point rather than a finished publication. The README gives two directions for changing it. A user can select a Hugo theme from `https://themes.gohugo.io`, passing the theme's GitHub user and repository name through the `theme` argument. The user can then add pages or posts, or migrate an existing website.

This separation matters for evaluation. blogdown does not dictate that every site use one visual style, and it does not require all content to be blog posts. The project is aimed at both blogging and general-purpose technical websites, but the actual structure still depends on the chosen theme and the files added to the site. A team that needs a specific content hierarchy or an existing site migration should inspect those parts before assuming that the default skeleton is sufficient.

Generator choice is another boundary. Hugo is the default, while Jekyll and Hexo are supported according to the README. The README does not explain the configuration differences among those generators, and it provides no compatibility matrix for themes and site content. Consequently, an adoption decision should not infer that every Hugo, Jekyll, or Hexo theme behaves identically. The documented core path is the one used by blogdown's own functions.

## Where blogdown is the wrong choice

The clearest wrong-tool case is a workflow that requires plain Markdown serving through `hugo server` while also expecting R Markdown files to build. The README explicitly warns that `hugo server` cannot build R Markdown. In that situation, choosing the raw command would discard the capability that motivated the use of blogdown.

blogdown is also a poor fit when the project is purely a static content site with no executable analysis, generated figures, tables, widgets, or technical writing requirements. The package adds an R Markdown and code execution layer, but the README does not claim that this layer improves a site that does not need it. A simpler Markdown and static generator workflow may have fewer moving parts, although the README does not document a specific alternative configuration for that comparison.

Another limitation is visible in the installation and site creation path. `new_site()` downloads a theme from GitHub and creates sample content, so the first run depends on external access and a suitable theme. The README does not explain offline installation, theme pinning, or rollback. Those behaviors should not be assumed when the site is built for an environment with restricted network access.

## Maintenance, licensing, and operational cost

The repository is not archived, and its last push was on 2026-06-19. Recent releases include `blogdown 1.24` on 2026-06-19, `blogdown 1.23` on 2026-01-18, and `blogdown 1.22` on 2025-10-28. This indicates recent project activity in the repository record. It does not by itself guarantee compatibility with every R, knitr, bookdown, Hugo, Jekyll, or Hexo combination, and the README does not document a support policy for those combinations.

The license field is unknown. The repository description lists an unknown license, so the article cannot state the license terms or advise how a site may be redistributed. Before adopting blogdown in a product or public site workflow, inspect the authoritative package metadata and repository license files. That is a compliance check, not a claim about the legal effect of any particular license.

The upgrade cost is not limited to installing a new R package. A blogdown site can combine package versions with an external generator and a downloaded theme. The README does not document automated theme updates, generator version pinning, or migration procedures for existing sites. Those omissions mean that upgrade planning must account for both the R package and the site toolchain. The available repository record supports recent release activity, but not a claim that upgrades are frictionless.

## Support sources and project-specific evaluation

The README directs users to the RStudio community and Stack Overflow for help. For RStudio community questions, it asks users to include the `blogdown` tag. Stack Overflow questions can use the `[r][blogdown]` tag combination. These are the documented support routes, and neither should be replaced with a generic claim that the project has a complete issue-resolution process.

For an engineer evaluating blogdown, the most useful first checks are concrete. Confirm that the site really needs rendered R output, verify that the chosen generator and theme can represent the intended pages and posts, and create a disposable site with `blogdown::new_site()`. Then test editing and saving `hello-world.Rmd`, followed by `blogdown::serve_site()`, to confirm the automatic rebuild and browser refresh described by the README.

The project is particularly suitable for a technical publishing stack where code and prose are maintained together. It is less suitable for a plain Markdown-only workflow or for a site whose requirements depend on undocumented generator and theme behavior. The package homepage is `https://pkgs.rstudio.com/blogdown/`, and the README also links to the project book at `https://pkg.yihui.org/blogdown/` for a fuller explanation of the workflow.

## Conclusion

Adopt blogdown when the site should combine R analysis or other knitr-supported code with editorial content, and Hugo is an acceptable publishing stack. Do not choose it as a replacement for a plain Markdown-only server workflow, because the README specifically says that `hugo server` does not build R Markdown. Before adoption, verify that your required content types fit the R Markdown and generator setup, and review the package license from the project metadata before distributing a site built with it.

## FAQ

### How do I install blogdown for R?

The README documents installing the released package from CRAN with `install.packages('blogdown')`. It also documents installing the development version from GitHub with `remotes::install_github('rstudio/blogdown')`.

### How do I create and preview a blogdown website?

Run `blogdown::new_site()` in an empty directory to create a site and sample content. Then use `blogdown::serve_site()` to build it, open it in a browser, and refresh the browser after edits.

### Can I use `hugo server` to serve a blogdown site?

The README says not to use `hugo server` for this purpose. It only understands plain Markdown files and cannot build R Markdown, so use `blogdown::serve_site()` for the documented blogdown workflow.

## Sources

- [Issues](https://github.com/rstudio/blogdown/issues)
- [Project website](https://pkgs.rstudio.com/blogdown/)
- [README](https://github.com/rstudio/blogdown/blob/main/README.md)
- [Releases](https://github.com/rstudio/blogdown/releases)
- [rstudio/blogdown on GitHub](https://github.com/rstudio/blogdown)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rstudio-blogdown