The WordPress Reading Settings screen decides what your front page shows, how many posts each listing page holds, and whether the whole site asks search engines to stay away. The SEO consequences come from how those choices interact with pagination and archive pages, not from any single field. If you run a publication, add a blog to a shop, or inherit client installs as an agency, the decision order in the "Start here" section keeps the changes safe.
The Reading Settings screen in one table
The WordPress documentation page Settings Reading screen (Opens in a new tab) describes a short list of options. You choose whether your latest posts or a static Page is the front page, set how many posts appear per page, and adjust syndication feed behavior. The labels quoted here are the English interface names; localized dashboards may show different wording.
| Option group | Label in the documentation | What it touches for SEO |
|---|---|---|
| Front page source | "Your latest posts", "A static page (select below)", "Homepage", "Posts page" | Which URL serves which content, and whether the same posts appear on two URLs |
| Listing size | "Blog pages show at most", "Syndication feeds show the most recent" | Number of paginated URLs, content per page, feed size |
| Visibility | "Discourage search engines from indexing this site" | Site-wide noindex request |
The visibility row deserves its own treatment because a forgotten checkbox can hide a whole launch. The sections here deal with the other two rows and how they shape pagination and archives.
Plugins can change the outcome
The documentation warns that static front page plugins and other plugins that control or restrict how posts are displayed may affect how these features work. A correct setting in the dashboard therefore does not prove that the live page behaves correctly. Page builders, theme templates and SEO plugin archive rules can all alter the final output, so inspect the real URLs after each change.
Start here: which setting to change first
Practical suggestion: order changes by blast radius.
- Check the visibility checkbox and any conflicting robots tags first, because they affect the whole site.
- Next set the front page and posts page pair, since it decides which URLs exist.
- Then verify pagination behavior: canonicals, links, scrolling alternatives.
- Last, tune posts per page and the feed.
Change one thing at a time and verify it in the page source. If you alter several settings together, you cannot tell which one produced a result.
Keep a short change log as you work: the date, the setting, the old value, the new value and the URL you checked afterwards. When a theme update or a plugin replacement later changes the output, that log tells you whether the Reading screen or something else is responsible, and it gives an agency a clear record to hand to the next person who opens the site.
Front page: latest posts or a static page
According to the documentation these settings work only if you have one or more Pages defined. With "Your latest posts" the front page lists recent posts, and the count follows "Blog pages show at most". With "A static page (select below)" a Page becomes the front page and you also pick the Page that will hold your posts. The documentation states that the home page and the posts page cannot be the same.
Two pages, two jobs
Practical suggestion: write down what each URL is for before touching the screen.
- A news site whose front page is the newest-article stream fits "Your latest posts". The theme controls the heading and intro text.
- A clinic, studio or shop that wants to explain its offer on the front page fits a static page, with the blog moved to a separate posts page that has its own menu label.
- A site that publishes rarely can keep the static model, because the front page then carries stable messaging instead of a thin list.
When the posts page is empty or missing
Two warnings in the documentation matter here. If you make no selection in the "Homepage" list, your blog effectively shows posts on both the front page and the posts page you specify. If you select no "Posts page", your posts are reachable only through other navigation such as category, calendar or archive links. Both gaps are configuration errors, not SEO tactics.
The documentation adds that any template assigned to the Page chosen as posts page is ignored, and that the theme's index.php, or home.php if it exists, controls how posts display. If you wrote an introduction in the page editor, test whether your theme prints it. The documentation does not say which theme types display it.
Three points readers mix up
- "I wrote an introduction on the page I chose as posts page, but it is not shown." The documentation says the assigned template is ignored and the theme's index.php or home.php drives the display. Whether the page's own editor content appears depends on the theme.
- "My password-protected posts page asks for no password." The documentation states that even if the selected Page is password protected, visitors will not be prompted for a password when viewing the posts page. Do not rely on page protection to hide the list.
- "I named my static front page template home.php and the blog broke." The documentation says not to name a static front page template home.php and suggests another name such as myhome.php.
Worked example: a recipe publication
Example scenario: a small recipe site starts with the default latest-posts front page, then wants a front page that introduces its cooking method and links to seasonal collections.
- Create two Pages, "Start" and "Recipes".
- In the Reading screen choose "A static page (select below)", set "Homepage" to Start and "Posts page" to Recipes.
- Load /recipes in a private window and check that posts appear, then read the source for a single robots tag.
- Pick the "Blog pages show at most" value by looking at card height on a phone.
- Open page 2 of the listing and confirm that its canonical points to itself.
- Decide on tag and date archives, and remove noindex pages from the sitemap.
The same site later adds a newsletter archive. Because the Reading screen has only one posts page, the newsletter needs its own post type or category rather than a second posts page, and its archive is judged with the archive decision table in the Archives section.
Posts per page and how deep the archive runs
The "Blog pages show at most" field takes a number of posts to show per page. The documentation does not recommend a value and does not describe the pagination URL format; permalink settings, theme and plugins decide that, so open a real second page to see the address.
The arithmetic is simple. An archive of 100 posts becomes ten pages at ten per page and five pages at twenty per page. Those two figures illustrate the effect only and are not recommendations.
Trade-offs to weigh
- Reader scanning: tall cards with images argue for fewer posts per page; short title lists can carry more.
- Page weight: every extra card adds markup and images to the first load.
- Depth: a small number pushes older posts further from the first page, so give them other routes such as category pages and related-post links.
- Stability: changing the number moves posts between page numbers. Check inbound links to old page numbers and any sitemap entries afterwards.
After you change the number
| Check | Why | Practical suggestion |
|---|---|---|
| Highest page number | Raising the value shrinks the page count | Request an old last-page URL and read the response |
| Sitemap output | Some sitemap plugins list paginated archives | Confirm each listed URL exists |
| Load time | More cards means more images | Test the first listing page on a phone |
| Older posts | They sit deeper in the sequence | Add category and related links |
An old page number that no longer holds posts should answer with an appropriate error or redirect, not a successful empty list. Run this check the same day you change the value.
What Google documents about paginated URLs
Google's pagination and incremental page loading documentation (Opens in a new tab) sits in the e-commerce section, and its principles apply to a blog listing as well. It asks you to give each page a unique URL, to avoid URL fragments (the text after #) for page numbers because Google ignores fragments, to avoid using the first page of a sequence as the canonical for every page, and to link pages with a href elements.
Parameters, fragments and canonicals
| Implementation | Documentation statement | Verdict |
|---|---|---|
| Separate URL per page, by path or parameter | Give each page a unique URL | Correct |
| Page number after # | Fragment identifiers are ignored | Avoid |
| Page 1 as canonical of every page | Do not use the first page as the canonical page | Avoid |
| Plain links from page to page | Googlebot follows a href links | Correct |
| rel prev and next | Google no longer uses these tags; other search engines may | Not required for Google |
If an older plugin still prints rel prev and next, nothing in the documentation calls that harmful. What it says is that Google does not rely on it, so the real links between pages are the evidence to check.
Filters and sort orders
For filter or sort variations of the same list, the documentation points to a noindex robots meta tag, or to a robots.txt rule that discourages crawling of specific URL patterns. On a WordPress site, that may mean search result pages, sort parameters or shop filters. Crawl your own site to find which of them exist.
Infinite scroll and load-more buttons
The documentation says these patterns are implemented with JavaScript and that Google's crawlers do not click buttons, and the documentation says they cannot be relied on to trigger functions that need a user action. If a theme loads older posts only through a button, keep a paginated alternative that exposes real links to them.
Archives: index, noindex or consolidate
The WordPress reading documentation gives no canonical or noindex rule for archives; the theme, an SEO plugin or custom code supplies those decisions. Everything in this section is therefore a practical suggestion. Category pagination and tag handling are covered in depth in SEO pagination for category pages and WordPress tag and archive pages: noindex or index.
| Archive type | Question to ask | Practical suggestion |
|---|---|---|
| Category | Does it have its own intro and a steady flow of posts? | Keep it indexable, with page 1 pointing to itself |
| Tag | Does each tag have a distinct purpose and several posts? | If not, noindex and prune tags |
| Date archive | Does it only repeat posts in calendar order? | Noindex when it adds nothing for readers |
| Author archive | On a one-author site, is it a copy of the blog list? | Noindex or disable |
| Search results | Can it produce endless variations? | Noindex |
These are questions, not rulings. An archive that reshuffles the same posts offers a reader nothing new, while a category with its own introduction can work as a topic hub.
Consistency across page 2 and beyond
Practical suggestion: apply a noindex decision to every page of the archive, or deliberately keep page 1 open and close the deeper pages. Keep only indexable URLs in the sitemap. Google's documentation on consolidating duplicate URLs (Opens in a new tab) ranks redirects and rel canonical as strong signals and sitemap inclusion as a weak one, and notes that none is required because Google can pick a canonical itself. Listing a noindex page in the sitemap sends mixed signals.
A second scenario: a local services company
Example scenario: a plumbing company has a blog as its front page because the first theme did that by default. Customers arrive looking for emergency contact details and service areas, not for the newest tip article.
- The owner lists what a first-time visitor needs: services, areas, a phone number, proof of work.
- Those needs fit a static front page, so a new Page carries them and the blog moves to a posts page labeled "Advice".
- Old blog-home links from directories now point at a page that changed its role. The owner decides whether they should be redirected to the new posts page, and tests them.
- Category archives such as "Boilers" get a short introduction so they read as hubs.
- The owner checks the sitemap and removes date archives that only repeat posts.
The scenario shows that the front page decision starts with visitor needs. The documentation does not claim a ranking benefit for either option.
Where wp_robots fits
For page-level exceptions WordPress offers the wp_robots filter. The hook reference (Opens in a new tab) says it filters the directives in the robots meta tag, was added in 5.7.0, starts from an empty array and only outputs the tag when necessary. It shows one example that adds noindex everywhere and another that limits noindex to a single post ID.
The reference does not describe how the filter relates to the Reading Settings checkbox. The reading documentation says the checkbox has produced a noindex,nofollow tag since version 5.3. Presenting the two as one mechanism would go beyond either page.
Conflicting robots tags
If a theme adds one directive and a plugin adds another, the source can end up with several robots meta tags. Google's robots meta tag specification (Opens in a new tab) says that when rules conflict, the more restrictive one applies. A single stray noindex therefore wins over a friendly plugin setting. Practical suggestion: find every source of the tag and manage it from one place.
Plugin or code
- One page, such as a thank-you page: the per-page robots field in your SEO plugin.
- A whole archive type: the plugin's archive settings, or the filter in a theme template.
- A conditional rule based on a query parameter: a small plugin or a filter in functions.php kept under version control.
Feeds and theme types: two smaller levers
Syndication feeds and copied content
"Syndication feeds show the most recent" sets how many posts people see when they download a feed. "For each article in a feed, show" chooses full text or an excerpt, and the documentation notes an excerpt could save bandwidth. It does not discuss SEO effects of feeds. Practical suggestion: if scrapers copying your articles worry you, an excerpt makes bulk copying less convenient, but weigh that against subscribers who expect full text in their reader.
Block themes and classic themes
The reading documentation does not separate block themes from classic ones. It only says the posts page ignores an assigned template and that index.php or home.php drives the display. If your block theme uses site editor templates, confirm the equivalent behavior in the theme's own documentation and on a live page. WordPress documentation and interface labels change between versions, so consult the current page before you apply anything.
Verifying the result after each change
Saving a setting proves nothing about the output. Because the documentation itself warns that plugins can change how these features work, run a short verification pass after every edit.
| Step | Where to look | Expected result |
|---|---|---|
| 1. Front page URL | Home address in a logged-out private window | The chosen static page or the latest-posts list |
| 2. Posts page URL | The blog link in your menu | A post list that differs from the front page |
| 3. Page source | Head section of both URLs | One robots tag at most, and a canonical pointing to the same URL |
| 4. Page 2 | The link under the list | A real a href link and a self-referencing canonical |
| 5. Sitemap | Your sitemap file | No noindex URL is listed |
| 6. Google's view | URL Inspection in Search Console | The HTML Google received and the canonical it selected |
Google's noindex documentation (Opens in a new tab) says the URL Inspection tool can request a recrawl and show the HTML Googlebot received.
The logged-in blind spot
An administrator session can hide problems. Caching plugins, the admin bar and session-dependent blocks alter the output. Practical suggestion: check in a private window, compare the page source rather than the rendered view, and purge the cache before you judge a result.
Choosing a consolidation tool: a comparison
Google's page on consolidating duplicate URLs ranks its methods by influence. When two addresses on your site return the same content, this table maps each method to the Reading screen problem it can answer.
| Method | What the documentation says | Fit for a Reading screen fault |
|---|---|---|
| Permanent redirect | Strong signal; server-side redirects take effect fastest | The old blog address is retired for good |
| rel canonical | Strong signal; in the head or an HTTP header, one method only, absolute URLs | Both addresses must keep working |
| Sitemap entry | Weaker signal; a suggestion | Listing the preferred addresses |
| robots.txt | Not for canonicalization; a disallowed URL may still be indexed without content | Not a duplicate fix |
| noindex | Not recommended within one site for this purpose | Only if the page should vanish from Search |
A misreading worth separating: noindex behind a robots.txt block
The robots meta tag documentation states that these rules are read only when a page can be crawled. If robots.txt blocks a URL, Google never sees the meta tag or the X-Robots-Tag header, so the instruction is ignored. When rules conflict, the more restrictive one applies. An archive you want kept out of the index therefore needs to stay crawlable.
Practical suggestion: verify crawlability and the noindex response as two separate checks. Merging them into one step hides which layer is failing.
Reading screen audit checklist
- Does the front page choice match what the site is for?
- If a static page is chosen, are "Homepage" and "Posts page" two different Pages?
- Was the posts page tested in a real browser, including any intro text?
- Was "Blog pages show at most" chosen with readers and page weight in mind?
- Do page numbers avoid fragments, and does each page canonicalize to itself?
- Does every page link to the next with a plain a href link?
- If infinite scroll is used, is there a paginated alternative?
- Has each archive type been judged separately?
- Are noindex archives absent from the sitemap?
- Is there exactly one robots meta tag in the source?
- Is the feed choice between full text and excerpt deliberate?
- Is the visibility checkbox cleared on the live site? The WordPress SEO settings checklist gives the wider order of settings.
Frequently Asked Questions
Does choosing a static front page improve rankings?
The documentation makes no such claim. A static page lets you write your own heading and text for the front page; do not tie ranking expectations to the setting.
What happens if I do not choose a posts page?
Per the WordPress documentation, leaving the Homepage list empty makes the blog show posts on both the front page and the posts page you name. Choosing no posts page leaves posts reachable only through category, calendar or archive links.
Should page 2 of a listing canonicalize to page 1?
No. Google's documentation advises against using the first page of a paginated sequence as the canonical page and says each page should have its own canonical URL.
Do I need rel prev and next tags?
Google's documentation says it no longer uses them, although other search engines may. For Google, what counts is unique URLs and a href links between the pages.
How many posts per page should I show?
The documentation recommends no number. Decide from card height, page weight and how easily older posts can be reached by other routes.
Must I noindex tag archives?
The reading documentation sets no rule. If a tag lacks a distinct purpose and enough posts, noindex is one practical option.
Does the wp_robots filter replace the visibility checkbox?
The hook reference does not describe a relationship between them. The filter exists to change directives in the robots meta tag and was added in version 5.7.0.
Conclusion
Reading Settings is a small screen with site-wide effects on URL structure, pagination depth and index visibility. Define the job of the front page first, give a static front page and a posts page separate Pages, keep unique URLs and real links in pagination, judge archives one type at a time, and confirm each change in the page source.
If you need a solid editorial foundation for your blog content, see our content writing service.
Post a comment
Please log in to leave a comment. Login