diff --git a/pkg_building.Rmd b/pkg_building.Rmd
index f835ca416..06f99896f 100644
--- a/pkg_building.Rmd
+++ b/pkg_building.Rmd
@@ -192,7 +192,7 @@ where issue\_id is the number of the issue in the software-review repository. Fo
 
 - Consider using `usethis::use_readme_rmd()` to get a template for a `README.Rmd` file and to automatically set up a pre-commit hook to ensure that `README.md` is always newer than `README.Rmd`.
 
-- Extensive examples should be kept for a vignette. If you want to make the vignettes more accessible before installing the package, we suggest [creating a website for your package](#website).
+- Extensive examples should be kept for a vignette. If you want to make the vignettes more accessible before installing the package, we suggest [creating a website for your package](#website). All packages submitted for software review must have a website.
 
 - Add a [code of conduct and contribution guidelines](#friendlyfiles).
 
@@ -271,7 +271,9 @@ Others have used the option to escape some URLs (change `<https://ropensci.org/>
 
 ## Documentation website {#website}
 
-We recommend creating a documentation website for your package using [`pkgdown`](https://github.com/r-lib/pkgdown). The R packages book features a [chapter on pkgdown](https://r-pkgs.org/website.html), and of course `pkgdown` has [its own documentation website](https://pkgdown.r-lib.org/).
+All packages submitted for software review must have a documentation website clearly linked in the source repository.
+We recommend using [`pkgdown`](https://github.com/r-lib/pkgdown) to create your website.
+The R packages book features a [chapter on pkgdown](https://r-pkgs.org/website.html), and of course `pkgdown` has [its own documentation website](https://pkgdown.r-lib.org/).
 
 There are a few elements we'd like to underline here.
 
diff --git a/softwarereview_author.Rmd b/softwarereview_author.Rmd
index 084521713..932100379 100644
--- a/softwarereview_author.Rmd
+++ b/softwarereview_author.Rmd
@@ -31,9 +31,10 @@ This concise guide presents the software peer review process for you as a packag
 
 ### Documentation
 
-- For any submission or pre-submission inquiry the README of your package should provide enough information about your package (goals, usage, similar packages) for the editors to assess its scope without having to install the package. Even better, set up a pkgdown website for allowing more detailed assessment of functionality online.
+- For any submission or pre-submission inquiry the README of your package should provide enough information about your package (goals, usage, similar packages) for the editors to assess its scope without having to install the package. 
   - At the submission stage, all major functions should be stable enough to be fully documented and tested; the README should make a strong case for the package.
   - Your README file should strive to explain your package's functionality and aims, assuming readers have little to no domain knowledge. All technical tems, including references to other software, should be clarified.
+- All packages require a website, with a URL specified in the "About" section of the GitHub repository. See the [Documentation website section](#website) for details.
 - Your package will continue to evolve after review, the chapter on *Package evolution* [provides guidance about the topic](#evolution).
 
 ## Preparing for Submission {#preparing-for-submission}