Recently Updated: 17 min read

WordPress Reading Settings and Pagination for SEO

WordPress Reading Settings and Pagination for SEO

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 groupLabel in the documentationWhat 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.

  1. Check the visibility checkbox and any conflicting robots tags first, because they affect the whole site.
  2. Next set the front page and posts page pair, since it decides which URLs exist.
  3. Then verify pagination behavior: canonicals, links, scrolling alternatives.
  4. 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

  1. "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.
  2. "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.
  3. "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.

  1. Create two Pages, "Start" and "Recipes".
  2. In the Reading screen choose "A static page (select below)", set "Homepage" to Start and "Posts page" to Recipes.
  3. Load /recipes in a private window and check that posts appear, then read the source for a single robots tag.
  4. Pick the "Blog pages show at most" value by looking at card height on a phone.
  5. Open page 2 of the listing and confirm that its canonical points to itself.
  6. 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

  1. Reader scanning: tall cards with images argue for fewer posts per page; short title lists can carry more.
  2. Page weight: every extra card adds markup and images to the first load.
  3. 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.
  4. 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

CheckWhyPractical suggestion
Highest page numberRaising the value shrinks the page countRequest an old last-page URL and read the response
Sitemap outputSome sitemap plugins list paginated archivesConfirm each listed URL exists
Load timeMore cards means more imagesTest the first listing page on a phone
Older postsThey sit deeper in the sequenceAdd 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

ImplementationDocumentation statementVerdict
Separate URL per page, by path or parameterGive each page a unique URLCorrect
Page number after #Fragment identifiers are ignoredAvoid
Page 1 as canonical of every pageDo not use the first page as the canonical pageAvoid
Plain links from page to pageGooglebot follows a href linksCorrect
rel prev and nextGoogle no longer uses these tags; other search engines mayNot 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 typeQuestion to askPractical suggestion
CategoryDoes it have its own intro and a steady flow of posts?Keep it indexable, with page 1 pointing to itself
TagDoes each tag have a distinct purpose and several posts?If not, noindex and prune tags
Date archiveDoes it only repeat posts in calendar order?Noindex when it adds nothing for readers
Author archiveOn a one-author site, is it a copy of the blog list?Noindex or disable
Search resultsCan 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.

  1. The owner lists what a first-time visitor needs: services, areas, a phone number, proof of work.
  2. Those needs fit a static front page, so a new Page carries them and the blog moves to a posts page labeled "Advice".
  3. 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.
  4. Category archives such as "Boilers" get a short introduction so they read as hubs.
  5. 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.

StepWhere to lookExpected result
1. Front page URLHome address in a logged-out private windowThe chosen static page or the latest-posts list
2. Posts page URLThe blog link in your menuA post list that differs from the front page
3. Page sourceHead section of both URLsOne robots tag at most, and a canonical pointing to the same URL
4. Page 2The link under the listA real a href link and a self-referencing canonical
5. SitemapYour sitemap fileNo noindex URL is listed
6. Google's viewURL Inspection in Search ConsoleThe 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.

MethodWhat the documentation saysFit for a Reading screen fault
Permanent redirectStrong signal; server-side redirects take effect fastestThe old blog address is retired for good
rel canonicalStrong signal; in the head or an HTTP header, one method only, absolute URLsBoth addresses must keep working
Sitemap entryWeaker signal; a suggestionListing the preferred addresses
robots.txtNot for canonicalization; a disallowed URL may still be indexed without contentNot a duplicate fix
noindexNot recommended within one site for this purposeOnly 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.

0 Comments

No comments yet for this article.

Post a comment

Please log in to leave a comment. Login