iFrame Internal Searchability with WordPress or Plug-Ins

Assuming WP and its PHP has proper access permissions to the external DB, getting data from it and generating page content with it is certainly feasible, but I’m unsure if there’s an existing plugin to help with this. There are too many variables involved for a plugin to accurately address most possibilities. You can use the wpdb class to connect to a DB, but you’d likely need to run your own custom queries.

Alternately, if this external DB is connected to a CMS of some sort, there might be an API you could interact with to get necessary data. Similar to WP’s REST API.

Searching iframes would likely be a tall order. It’s easy enough to find iframes in WP content, but searching within the iframe is another matter. Searching a page with iframes that has already been loaded is feasible, but not searching for specific iframe content in all pages. Iframe content exists at its source, not within WP. Even if it were feasible to search at their source, the relationship with WP pages that contain related iframes is tenuous at best. If such a search were at all possible, it’d be so slow to be practically unusable.

Thank you for taking the time to respond to my inquiry.

We are listing vehicles and we have a piece of software that pulls vehicle specs for us. If I had to guess the efficiency gain from this integration, I’d say it’s saving us from having to double the size of the department building the listings, so it’s not a piece of software that we will be removing from our tech-stack any time soon from any angle I can see.

The downside, is that it only pushes out iFrames for the listings, and though it will push to other sites, it does so as an iFrame.

I’ve created a simple landing page for lead gen that I am using as a test case for creating “Listing Previews” which have some of the highlights and best photos from the ads and links to the full iFrame advertisement linked in two places at the moment.

I figured that if there wasn’t a plugin available that will capture the data from iFrames and return it for their standard query, that any use of these iFrames, embedded or otherwise would result in a cumbersome process for both us, the seller trying to find their vehicle on our site, and the shopper trying to shop our inventory.

I guess the real questions I’ll have to figure out from here, is who owns the data or, at a minimum, if we have the right to use the data that is auto-pulled for the specs on the listing previews as there are a million ways to easily make that internally searchable and have it provide value for our SEO efforts.

The second is whether embedding the iFrames on the listing previews vs just adding links to the full listings affects page load speed more to impact our SEO as well.

The DB tries to act as a CMS but since it only pushes iFrames, I’d hardly consider it one. They also have refused to share their API to the owners of the company thus far, so I’m doubting I’ll have any better luck there.

I haven’t worked with WordPress in so long, I’m open to any and all advice from people that have navigated similar challenges. I’m of the belief that WordPress is a better way to go than Wix either way, and if I go the Bootstrap route I foresee myself working a lot of 14 hour days in perpetuity, which isn’t a great trade-off for being able to customize as much as I’d like with Bootstrap vs WordPress.

I am also looking into adding Google Custom Search as a potential solution, but don’t understand why this wouldn’t be an option that a moderator would recommend.

If you can help me understand how this wouldn’t be a functional option, it would be greatly appreciated.

I do understand that we still wouldn’t get SEO credit for the content within the iFrames, but the customers provide us with enough details that we should be able to move the needle in that area other ways.

• This reply was modified 3 weeks, 4 days ago by dcfsbovehicles.

Don’t put too much importance in that moderator flag. Unless we’re actually taking moderator actions such as handling forum guideline deviations, consider advice from us to be like anyone else here in the forums. People with a wide range of skills and knowledge who can sometimes be wrong or omit information. Like most people here, we are human ??

I don’t consider Google search to be reliable in finding everything I’m searching for on a particular site. Pages with what I’m looking for which have little SEO juice are unlikely to show up in a Google search. That said, you may not have a better option for finding content within iframes. In order to do that yourself you’d need to maintain all iframe content within your own DB instead of fetching it dynamically from its source.

Thank you for that and I really appreciate the input of anyone from the community. I was just pointing out that he is a moderator because it seemed like it signaled overall authority on the matter, which I think you understood.

I have more of a background in backend, particularly CRM, than frontend so I am open to all advice from anyone who knows more than me.

I think the bigger issue is if we will have access to the data for the DB if the piece of our tech-stack that we can’t live without won’t even share API info.

From there, we get into how to structure and maintain that DB, which isn’t an area I’m particularly strong in because it’s something I’ve generally relied on CRMs for.

Thank you so much responding and any more advice is greatly appreciated!

If the iframe data you’d like to search is within your site’s “classic showroom” page, that iframe already has a search feature. It interacts with the API at showroom.auction123.com. I thinks it’s infeasible to import this kind of data for your own search functionality because there’s too much data and it’s constantly changing. It might be feasible to reverse engineer the API parameters by using your browser’s network developer tool to see how the iframe’s search feature makes its API requests. The response comes back as JSON data, so the data would need to be parsed into a more usable data structure, typical of any RESTful API response. This data could then be used to dynamically generate a search results page. You’d basically be replicating what the iframe’s script already does for you, so it’s unclear why you wouldn’t simply rely upon the iframe’s search feature.

I realize this iframe is possibly not even what you’re asking about. Without more specific information about your intention, it’s difficult to offer any further advice.

I think the better solution is to manually get the data from the customers and do our own development with listing previews, then linking to the iFrame pages.

iFrames can be extremely valuable in a lot of use cases (like embedding a Stripe iFrame with terms and conditions into a page), but the iFrame functionality here is really only for the convenience of the company producing them. Companies that do that will become obsolete one way or another eventually so I don’t view it as a permanent issue.

In the mean time, while other companies are relying on a company that won’t share it’s API and only pushes out iFrames, we gain a competitive advantage in multiple areas over any of these competitors.

Templating it out and picking the winners for the pictures provided should improve UX/UI for both buyer and seller and we then have control over the overall SEO preview listings. Go look at a $300,000 RV on RVTrader or a car for auction on Bring-A-Trailer.

On RVTrader you will usually see ~75 pictures with tiny thumbnails that you can use a form of lightbox to cycle thru but in ten minutes you’ll be wishing your computer would blow up and take you with it rather than shop the site again.

Bring-A-Trailer, many items have like 300 photos of the undercarriage of a car. It’s car porn. If you’re looking at the people posting in their forums related to these auctions, they usually have never even purchased a vehicle from Bring-A-Trailer. They’re just there to talk trash about cars they can’t afford.

By training and embedding Google search for internal purposes, I think we stand the best chance at both gaining utility from the search function and testing our SEO efforts. This is unless there is a plug-in that can do it better, which I am absolutely more than open to being advised on.

Plus, the site is currently hosted on Wix, which states on their support page that iFrames are not searchable on there by their internal search function (which I’ve got some major beef with them about seeing as though no one in support has ever found it necessary to mention to their customer – companies like that I don’t attach myself to big picture because they’ll lose in their competitive landscape eventually).

Why go thru all the trouble of reinventing the wheel and parsing JSON data to my specific use case, when the utility can be provided by a plug-in? It’s the same reason I licensed a better version of lightbox than these other sites use.

The key challenges there are manual upkeep, which requires either a high level of organization of just a good CMS which there are plenty of (I also have no life outside of work so who cares about the time spent), but also doing some A/B testing to see how page load speeds are effected by linking vs embedding the iFrames.

If that didn’t work, I’d then pivot to something like writing a parser for JSON data and dealing with APIs that we have trouble getting manual access to. Let me know what your thoughts are on that.

Inability to search iframes is not unique to Wix. No CMS will be able to use its DB search function to search in iframe content sourced elsewhere. Such search functions simply cannot access the remotely sourced data.

If you’re going to host your own data, then any CMS should be able to search the data. Maintaining such data in a constantly changing environment is a very large task unless it can be automated somehow. Even then, this automation would likely need periodic maintenance for it to continue to function over time.

Good SEO practices are important so people can find what they’re looking for. Having a more focused site specific search feature is desirable but infeasible when remotely sourced iframe content is involved. The only way your site’s search feature can search within iframe content is if there is an API it can interact with. If the API’s protocols are not documented, attempting to reverse engineer how to access it is far from ideal, the required protocols could change at any time without warning. There are not really any reasonable options that I can see.

I couldn’t agree more. The last thing I want to do is build around variables that I can’t control when there is an option to build around variables that I can control.

My beef with Wix is not that they can’t search iFrames. It’s that no one mentioned it over a very long period of time when it was clearly going to affect UX for buyers and sellers. If that’s how things are handled there, it’s not a place that I think is wise to partner with in the big-picture. There are plenty of good use cases for Wix, this just isn’t one of them.

Based on what we are doing, our reps should be having conversations with customers where the main high-lighted items of the vehicles are discussed during the sales process and the images are obtained by us directly from the customer, meaning we have rights to the images and data gathered. Though it would be a lot of work, even with a good CMS, it gives us the best chance to improve UX/UI for both customer and seller, as well as, gain control over our SEO capabilities.

As far as being able to pull from the iFrames, would it be ideal to be able to search every single feature or spec related to a vehicle for SEO purposes?

Of course it would.

That said, it stands to reason that if we are trying to match search intent, there will be a lot more people searching for, say, a 5th Wheel with a kitchen island and solar panels (which should be gathered in a conversation with a rep, as that is what the seller is excited about) then there would be people searching for a 5th Wheel with a shower door type that is either plastic or glass, or a that the interior walls are wallpaper, vinyl or tile.

That way we can use the the listing previews to show the sexy stuff that matters the most, the images to highlight those key points along with on-page SEO listing those important specs, and a link or embedded iFrame to give them the option to shop the entire unit in a more user friendly way than our competition currently offers.

Will the extra work suck?

Yes.

Would I do it if there was a reliable way to consistently produce strong results to meet all of our criteria in meaningful and impactful ways?

No I wouldn’t.

Part of working with small businesses is resource allocation vs ROI and this appears to be the best way to allocate one of our most finite resources (time) for ROI until a better option that is not contingent on iFrames is produced by the free market (assuming this doesn’t somehow turn into a regulated market, in which case, it will just never be a good market to shop in anyway).

Part of this, as well, is that this is my first venture into SEO, so I need to budget my time in a way that will be productive for the organization and, in my estimation, there is no more valuable way to spend that time than making sure our listings look and function the way sellers would want, and reach as many buyers as possible to ensure we sell the most vehicles in the space.

Once we meet those criteria, I can’t think of anything any competitor is going to do other than buying eBay Motors that will take us off the top spot in the space.

Also, your feedback has been really insightful and appreciated.

The parsing of the JSON strings is actually a great idea but the intricacies of it vs time expenditure on my end does not seem like something I should lean in to compared to these other aspects.

You wouldn’t be the first person to consider leaving Wix for another CMS ?? There are many valid reasons to do so, but inability to search within iframe content shouldn’t be one of them since any CMS would have the same limitation.

You’ve some important decisions to make regarding where to spend your finite time against what trade-offs you’d need to make. SEO is obviously important. Even with the best SEO efforts, you’re unlikely to gain a top listing, as you’re well aware. Just getting on the first page would be a wonderful accomplishment. Search rankings reward useful, unique information. If your site is composed of mostly iframe content, while it may be useful information, I suspect it is not unique. If you’re pulling in iframe content from somewhere else, others like you are probably doing the same.

WordPress (the .org version) is well suited for implementing custom DB content. There’s something to be said about managing your own unique data. Then it’s quite conceivable to filter searches by all sorts of criteria like glass shower enclosures or tile floors. Of course such detailed information would need to be in your DB in order to filter that way. Such detail may not be available in remote DBs, so having it available would give your business and customers an edge over the others. The big problem with your own detailed DB is the amount of time needed to create and maintain such a large DB.

Consider your options carefully and choose well. I wish you all the best in your endeavor.

I appreciate your kind words and all your advice.

What I’m actually planning on doing is not running the CMS via the iFrame information, but manual information that is more targeted and thus more easily managed.

The reason I’d be leaving Wix is for that CMS, combined with the fact that no one found it necessary to mention to us that this was a limitation.

Right now I am just testing with a landing page with a bunch of test cases for the custom websites so I’ll keep you updated on my progress, should the project continue to move forward.

Since you do seem to be an authority on the matter, our of curiosity, how would you approach the DB creation if it were you?

For clarity, one thing that would be a major factor in my deciding how to build that DB would be security. I’d prefer to go without a cloud option unless I can hold that cloud option accountable for any data leaks (we recently had a “competitor” – more of a wannabe – start stealing our images off eBay and acting like they were listing vehicles that we are in an attempt to try to boost their credibility, because they have no items sold on eBay Motors). I wouldn’t expect any kind of sophisticated issues with security, but enough to cover the run of the mill issues would suffice.

The issue with data theft is if something appears on the front end of a site, someone could scrape it and use it for their own purposes. You could watermark your images so it’s clear what the source is. The problem is if the watermark is large enough to not be easily cropped out, it’s rather unsightly and is not a good look on your own site. It’s possible to disable right click context menus that have the “Save image as…” option. This is largely ineffective, all it does is make the manual scraping of images slightly more difficult. It does nothing to deter an automated scraper script. The most effective measure against data theft is in taking legal action, but that can get expensive. Even then, it’s no guarantee the theft would stop.

Assuming your site will be WP based, the easiest way to manage data is to use the built-in functionality of WP. Vehicles can be organized as a custom post type, the same way e-commerce plugins handle products. The various vehicle attributes can be handled through post meta data. But the problem with using the built-in postmeta table is its schema is not very efficient for filtered queries. It’s fine for data that would not be used to qualify queries or for relatively small datasets. For filtering queries in large datasets, you’re better off implementing a custom table where each column is for a specific attribute. The challenge is to come up with a schema that can filter queries in enough detail without needing so many different columns that the process becomes too cumbersome. You’ll need to accept that it will not be possible to filter by any small esoteric detail. Try to limit filtering to what’s most important for customers. The more esoteric unfilterable details can be kept in postmeta.

You are speaking my language as far using the small data-sets for qualified queries so that table would likely be functional. I am not so worried about scraping, so much as, if we are housing this data it would likely be housed either along with or adjacent to the total data set that we are not running queries on. This information would also likely be housed in the same place or adjacent to the actual customer information. So screen scraping isn’t my biggest concern. If they keep doing that I’ll just build out the infrastructure that they would be scraping and selling fake cars without making it largely public, then report them for it, and put them out of business. It’s actual security around housing the data that I want ensure is sound. Keep in mind, I haven’t built on WP in years so I’m kinda fishing for whatever information you can provide me.

I’d need to learn more about working with the larger datasets, so if you have any guidance on if I have to pivot that direction, it would be greatly helpful.