How to Show Different Table Views to Logged-In vs Guest Users in WordPress

Updated July 2026 • 7 min read • By Fahad Murtaza

Many WordPress sites need to show table data publicly, for SEO, for prospects, for general reference, while giving authenticated users a richer experience with more columns, editing capabilities, or export controls. TableCrafter supports two approaches to this guest-vs.-logged-in split: a role-settings approach that works entirely within the plugin configuration, and a template conditional approach using WordPress's is_user_logged_in() function with two separate shortcodes. This guide covers both. WordPress powers 43% of all websites globally (W3Techs, July 2026), and TableCrafter bridges the gap between the data you collect and the tables your users need to see, no custom PHP, no dashboard access required for viewers, and no per-row limits on the free tier. The free version on WordPress.org supports CSV, JSON, Google Sheets, and Excel. Pro adds Gravity Forms, Airtable, Notion, WooCommerce, REST APIs, inline cell editing, export to CSV/PDF, role-based column visibility, and auto-refresh. Every table embeds on. External database connections via REST APIs reduce WordPress database query load by up to 55% (Kinsta performance analysis, 2024).

What Is Approach 1: TableCrafter Role Settings (Recommended for Most Cases)?

The simplest implementation uses a single shortcode and TableCrafter's built-in role settings to deliver different experiences based on authentication state.

Configuration Steps

Open the table in TableCrafter → Tables and go to Access & Permissions:

1. In Allowed Viewer Roles, check the Guests (not logged in) option and every logged-in role you want to have access (Subscriber, Editor, Administrator, etc.).
2. In Allowed Editor Roles, check only the logged-in roles that should edit, do not check Guest.
3. In the Columns tab, mark any columns that should be hidden from guests as not visible to the Guest role.

Deploy the shortcode on the page:

[tablecrafter id="6" filter="true" search="true" edit="true" export="true"]

Guests visiting the page see a filtered, searchable read-only table with only public columns. Logged-in Editors see the same table with additional columns and clickable editable cells. Administrators see everything including admin-only columns.

Limitations of This Approach

The role settings approach works well when the guest and logged-in views share the same data source and column structure, guests see a subset of what logged-in users see. If you need fundamentally different tables (different data sources, different column orders, different filter configurations) for guests vs. logged-in users, Approach 2 gives you more control.

What Is Approach 2: Two Shortcodes with a Template Conditional?

This approach creates two distinct TableCrafter table configurations and uses a PHP conditional to display the appropriate one based on authentication state. The two tables can have completely different settings, column sets, and even different data sources.

Step 1: Create Two Table Configurations

In TableCrafter → Tables, create two tables:

• Table ID 10, Public View: Five columns, no edit, no export, Guest in Allowed Viewer Roles. This is the SEO-friendly public table.
• Table ID 11, Member View: Eight columns including sensitive data, edit enabled, export enabled, Guest NOT in Allowed Viewer Roles, Subscriber + Editor + Administrator in Allowed Viewer Roles.

Step 2: Add the Conditional Template

In your WordPress theme's page template, or in a Custom HTML widget on the target page, use the following PHP template tag pattern:

<?php if ( is_user_logged_in() ) : ?>
  [tablecrafter id="11" edit="true" filter="true" search="true" export="true"]
<?php else : ?>
  [tablecrafter id="10" filter="true" search="true"]
<?php endif; ?>

Because shortcodes inside PHP template files are not automatically processed, call do_shortcode() around each:

<?php if ( is_user_logged_in() ) : ?>
  <?php echo do_shortcode( '[tablecrafter id="11" edit="true" filter="true" search="true" export="true"]' ); ?>
<?php else : ?>
  <?php echo do_shortcode( '[tablecrafter id="10" filter="true" search="true"]' ); ?>
<?php endif; ?>

If you are using Elementor or a similar page builder that does not provide direct PHP access, use a shortcode-wrapper plugin or the Elementor PHP widget to execute this conditional. An alternative is a shortcode macro plugin that wraps the conditional in its own shortcode:

[if_logged_in]
  [tablecrafter id="11" edit="true" filter="true" search="true" export="true"]
[/if_logged_in]
[if_logged_out]
  [tablecrafter id="10" filter="true" search="true"]
[/if_logged_out]

How Does Caching Considerations Work?

Full-page caching (WP Rocket, NitroPack, WP Super Cache) caches the rendered HTML. If a guest loads a page and that HTML is cached, a logged-in user visiting next might see the guest version from cache.

Mitigate this with two strategies:

1. Cache exclusion by cookie: Configure your caching plugin to serve uncached pages to users with the WordPress authentication cookie (wordpress_logged_in_*). Most major caching plugins support this by default, but verify it is active.
2. Fragment caching via AJAX: Because TableCrafter loads table data via AJAX after page load, the page HTML itself can be cached. The AJAX call runs client-side and is authenticated, so the correct role-filtered data is always fetched regardless of which HTML page was served from cache. This is the default TableCrafter behavior and is the primary reason role filtering is AJAX-based rather than server-rendered.

How Does SEO Implications of the Guest View Work?

Googlebot visits as an unauthenticated user. If you enable the Guest role in Allowed Viewer Roles, Googlebot will crawl and index the public table data. This can be beneficial for product catalog tables, reference data tables, or any table where search visibility adds value.

If the table contains private data that should not be indexed, ensure Guest is not in Allowed Viewer Roles and the page itself requires login. A page that requires authentication will not be crawled meaningfully by Googlebot.

The configuration you set here applies to every visitor who loads a page containing this table, regardless of whether they are logged in. Role-specific overrides for columns and rows are a separate layer and do not replace these global display settings. Apply global settings first, then add role restrictions as needed for tables that serve multiple user types.

How Does Testing the Conditional Work?

Test both states explicitly rather than assuming the conditional works:

1. In a private/incognito window (unauthenticated), navigate to the page. Confirm the public table appears with the correct columns.
2. Log in as a Subscriber in the same window. Confirm the member table appears with additional columns and editing controls.
3. Log out again. Confirm the public table returns.

What Are the Next Steps?

With guest vs. logged-in views working, the next advanced pattern is pre-filtering a table via URL parameters while also enforcing role restrictions. The guide on combining URL parameter filters with role-restricted tables shows how to pass a ?status=Pending URL parameter to a table that is also locked to logged-in editors, a powerful pattern for shared deep links in team workflows.