Hi @pmluther
Is it possible that you have the install in question pointing to a dev/local index? Meaning you have your live/prod index and you’ve checked that one in the Algolia dashboard, but the website is pointing to an incorrect index?
Alternatively, perhaps just some of the indexed content has the correct URLs, but the test queries are returning results that don’t. May be worth doing a bulk re-indexing of the live site, assuming that live is pointed to the live index.
May be worth checking out https://pluginize.com/wp-search-with-algolia-index-management-and-site-launch-best-practices/ where we offer ideas and best practices to help keep indexes separated and “clean” so to speak.
The index is supposed to be pointing to a dev/local site, so that part is correct. It’s a testing site that isn’t live, just used for experimental purposes. I have done a bulk re-index several times, but the issue remains the same. I can see the correct permalink in my Algolia index, but it’s not getting returned in the search results.
Is this a semi-public website, where I could get potential access to see this first-hand? Or is this all literal local for you and just your machine?
I’m wondering what’s coming in for XHR/AJAX requests. We’d be able to verify index being queried against, and raw result object data above just what may be getting rendered.
Nonetheless, it sounds like SOMETHING isn’t lining up like expected/needed, or the re-indexing is failing somehow. Perhaps try editing and saving a specific example with the incorrect URL used. It should re-index that specific post upon save, instead of trying to go through all of them.
Yes, it’s a completely local site that’s just on my machine. I’ll try editing one of the posts and seeing that forces it to index the correct link.
If you check your Network/Console dev tools, you should see POST requests similar to this:
https://XYZ-dsn.algolia.net/1/indexes/*/queries?x-algolia-agent=Algolia%20for%20JavaScript%20(4.18.0)%3B%20Browser%20(lite)%3B%20instantsearch.js%20(4.78.3)%3B%20JS%20Helper%20(3.25.0)&x-algolia-api-key=XYZXYZ&x-algolia-application-id=XYZ
With Chrome’s “Payload” tab, you can see what is getting sent with the request and the “Preview” tab the response. The “hits” property is going to hold the result objects, and should match up with what you’re seeing when browsing the index via Algolia dashboard, if things are pulling from the intended index and everything.
Looking at the network and console tools, it looks like the requests are getting blocked by the CORS setting, so could that be why the results are getting the wrong permalinks?
I’m not going to say no, but at the same time, logically you wouldn’t be seeing any results if the requests are getting blocked.
That said, unsure if you have any browser addons around privacy and the like, just in case those are interfering somehow.
I was thinking that as well–that I wouldn’t see any results if that was the issue–but I also have seen a lot of weird things happen with websites in the past.
That said, I did deactivate my privacy addons, but it didn’t make any difference.
At the moment, I don’t have any other ideas on what to check given that i also don’t have access to see things in action, since it’s all local for just you.
My head is still saying it’s either a source’s indexed content issue, or a source used mismatch issue.
I may have to set this problem on the side for a bit and come back to it later. Thank you for your help!
