Certain Product Variants Not Indexed

Hi @lhqcsi — thanks for waiting on this, and sorry for the delay.

Here’s the cause. Variations aren’t indexed as records at all right now. WooCommerce registers product_variation as a non-public post type, so it’s excluded from the searchable index and only the parent product ever gets a record. The index also only searches three attributes — post_title, taxonomies, and content — and SKUs aren’t included on the record by default.

That means a variant SKU is only findable when the string already happens to appear in the parent product’s title, attribute terms, or description. M4-500, M4-20, and M4-025 are matching from the parent’s content; M4-100 isn’t present in any of those places, so there’s nothing for Algolia to match. It also explains the difference you saw with simple products: their SKU is usually already in the indexed content, so re-saving pushes a record that contains it. Here, Update just re-pushes a record that never contained M4-100, which is why it doesn’t help.

We’re working on proper variation support and expect to ship it in an upcoming release. We’ll follow up on this thread once it’s out.

In the meantime, as a separate workaround, you can make variation SKUs searchable yourself without waiting for us. Use the algolia_post_shared_attributes and algolia_searchable_post_shared_attributes filters to attach the variation SKUs to the parent product’s record, add that new attribute to searchableAttributes via algolia_searchable_posts_index_settings, then re-index. Searching any variation SKU will return the parent product. Let us know if you’d like a working snippet and we’ll post one.

Thanks for the extra detail. There is a much shorter fix worth trying before rebuilding the attributes.

Go to Algolia → Autocomplete and check the list of indices. You should see a Variations card (wp_posts_product_variation). Check whether it is enabled.

If it is not enabled, enable it, save the settings, and run a re-index. In the plugin, this determines which indices are synced. Enabling Variations is what causes the variation records to be created.

WooCommerce names each variation post using the parent product name and attribute values. In your case, the variation title contains M4-100, and post_title is one of the searchable attributes for that index. That is why the variation becomes searchable once a record exists for it.

If Variations is already enabled, the issue may simply be that this particular variation did not have an Algolia record yet. This can happen if the index was enabled but the site was never fully re-indexed. Variations saved after the index was enabled may have records, while older variations do not.

Deleting and re-adding the attribute recreated the variation posts and triggered a save, which then created the Algolia records. So it produced the expected result, but a full re-index of the Variations index should accomplish the same thing for the entire catalog without having to edit products manually.

I would start there first, as it may also resolve other variations that have not been identified yet.

There are a few things to keep in mind with this approach:

• Variations will appear in the autocomplete dropdown as their own section. This is controlled by the same setting that enables the Variations index.
• Some duplication is expected. A broad search may return both the parent product and multiple variations because they are indexed separately.
• Check the variation links. WooCommerce variations use a non-public post type and do not have their own rewrite rules. As a result, the permalink stored on a variation record may not be a usable product URL. I recommend checking the permalink field on a variation record in the Algolia dashboard before exposing these results to customers.

Also, this approach only affects autocomplete. The search results page uses the searchable posts index, which does not include variations, so variation records will not appear there.

There are also two limitations worth mentioning:

1. Variation SKUs are still not searchable because the SKU is stored as post meta and is not included in the variation record by default.
2. For products with three or more attributes, WooCommerce may not include all attribute values in the variation title, so some variations may still not be discoverable by their full attribute combination.

If you need SKU and attribute-value searching across the entire catalog, an alternative is to add the variation data to the parent product record instead. This approach has a few advantages: searches return the parent product, the product has a valid URL, the result appears in both autocomplete and the search results page, and it avoids duplicate parent/variation results.

The following snippet adds every variation’s SKU and attribute values to the parent product record and makes that data searchable.

Please test this on a local or staging environment first. It changes the Algolia index configuration and requires a full re-index.

Create:

wp-content/mu-plugins/algolia-variation-skus.php

<?php
/**
 * Plugin Name: Algolia Variation SKUs
 */

add_filter( 'algolia_post_shared_attributes', 'wpswa_add_variation_data', 10, 2 );
add_filter( 'algolia_searchable_post_shared_attributes', 'wpswa_add_variation_data', 10, 2 );

function wpswa_add_variation_data( array $attributes, WP_Post $post ) : array {
	if ( 'product' !== $post->post_type || ! function_exists( 'wc_get_product' ) ) {
		return $attributes;
	}

	$product = wc_get_product( $post->ID );

	if ( ! $product ) {
		return $attributes;
	}

	$values = array( $product->get_sku() );

	if ( $product->is_type( 'variable' ) ) {
		foreach ( $product->get_children() as $variation_id ) {
			$variation = wc_get_product( $variation_id );

			if ( ! $variation ) {
				continue;
			}

			$values[] = $variation->get_sku();

			foreach ( $variation->get_variation_attributes() as $value ) {
				$values[] = $value;
			}
		}
	}

	$attributes['variant_skus'] = array_values(
		array_unique( array_filter( array_map( 'strval', $values ) ) )
	);

	return $attributes;
}

add_filter( 'algolia_searchable_posts_index_settings', 'wpswa_searchable_variation_data' );
add_filter( 'algolia_posts_product_index_settings', 'wpswa_searchable_variation_data' );

function wpswa_searchable_variation_data( array $settings ) : array {
	$settings['searchableAttributes'][] = 'unordered(variant_skus)';

	return $settings;
}

To apply it

1. Save the file on your local or staging site. The same code can also be placed in a child theme’s functions.php. If staging shares Algolia credentials with production, make sure it uses a different index name prefix so the re-index does not overwrite the production index.
2. Run a full re-index. Both the additional record data and the searchable attribute configuration need to be sent to Algolia.
3. Open the index in the Algolia dashboard and verify that a variable product has a variant_skus array containing its variation SKUs. Also verify that variant_skus appears under Configuration → Searchable attributes.
4. Search for a variation SKU. The parent product should be returned.
5. Once everything looks correct, deploy the same code to production and re-index there.

One caveat is that saving a variation by itself does not always re-save the parent product. If you change a variation SKU later, update the parent product as well to make sure its Algolia record is refreshed.

Proper first-class variation support is something we are working toward for an upcoming release.