Best Search Stack?

A client is wanting to incorporate a site-wide search box into their website. I know there are a few options out there…which one do you think is the easiest to implement into a fairly large website? And which one is the best from the visitor’s perspective?

I have used RapidSearch Pro and it works well. It uses your sitemap to build an index. To your site visitors it looks professional. I have also used Google Custom Search boxes. The advantage to google is that is updates automatically. With RapidSearch you have to re-index the sitemap but it looks more professional than google.


RapidSearch (@willwood) also has:
RapidSearchGo (uses DuckDuckGo)
RapidSearch (uses Google)
RapidSearchLive(build your own Flatefile Index based on Metadata)
and the mentioned RapidSearchPro (builds a MySQL database of all content).

The Google and DuckDucvkGo versions you are dependant on when and what the search engines index. The Live and Pro you build the indexes.


I have found a non-RW tool to be great. Check out Zoom search engine. It has so many options it can be a bit daunting to understand and setup but once done, and if you provide weigtings properly, it is outstanding. I have it running on a 1500 page site full of reports, articles, store, etc and and you can assign categories to refine search returns. It installs on your Mac, you point it to your site, it creates the files necessary, then you upload them to your website. There is code you place on a RW page for the “search” page and returns. It is an outstanding product.


Thanks for the recommendation, @Parker and @teefers :slight_smile:

With RapidSearch Pro, do I have to update the index manually every now and then? Ideally, I’d like something that keeps itself up to date and requires no maintenance…

1 Like

Per RapidSearchPro documentation:

You must build your search index immediately after you first publish your RapidSearch Pro page. You should also re-build your search index if you make changes to multiple pages on your RapidWeaver website. RapidSearch Pro will detect if the sitemap file has been updated recently, and will display a notification suggesting the search index be rebuilt.

I believe that both RapidSearch Pro and RapidSearch Live both require you to "mainly rebuild the indexes. I also think they both a think are reliant on the"sitemap.xml file to use as the “base” for what gets indexed for searching. That being said, the built-in sitemap.xml file that RapidWeaver builds may not be adequate. My understanding of the built-in sitemap is it only displays pages that are in the “use in Navigation”. Sitemap Plus may give you more control. Neither the built-in sitemap or Sitemap Plus will include generated pages from CMS’s (Armadillo, Pulse CMS, TCMS or Poster) as those pages don’t exist within RapidWeaver.

There are options for generating a sitemap on a published site( this would include generated pages). I’ve had good luck using Integrity Plus, it generates a “complete” sitemap as well as Link checking. There are plenty of other apps out that do similar functions.



Thanks for the heads-up on Integrity Plus. I may just have to use that. This would mean creating a new sitemap and uploading to server every time there is an update but it would catch many more pages than standard sitemap file created by RW. I use Google custom search now for a site because I didn’t want to rebuild the search index every time but I may just have to bite the bullet.


Is there much maintenance needed for RapidSearch Pro? (i.e. do I have to log in often to keep the database indexed or up to date?

@garth Like any search solution, the database only needs rebuilding if items are added or removed from the website, and you want those changes included. Basically if the sitemap changes, that is a good indication that you might want to login and do a quick rebuild of the search database too.

A clear advantage of using RapidSearch Pro, RapidSearch Live or SimpleSearch stacks is that you are in complete 100% control of when the search database needs a rebuild. Whereas if you’re relying on a third-party (like Google or DuckDuckGo) it can take several days or even weeks before website changes are reflected in their search databases.

The type of content you are publishing and the frequency of changes to your website is an important factor, when considering which search solution to use. What works for one person, may be less suitable for someone else. Therefore there’s no ‘best search stack’ as such! There are different solutions for different scenarios.

1 Like

Thanks for the reply, Will!

The most frequent changes will be weekly blog posts…does this mean that we’ll need to update the database every time the client publishes a new post?

What are you using for blog posting? Some do generate a sitemap of their own (TCMS does) which in turn can be manually referenced in the existing “main” sitemap, if you follow.

Once created you’d have to make sure you switched off sitemap generator in RW, so any publishing update didn’t wipeout the custom sitemap you’ve made.

Yes, I’m using Total CMS for blog posts. So if I’m using TCMS, then I don’t need to rebuild the database?

You lost me at “daunting to understand and setup”

Depends on the structure of the blog and how it is being managed. If each new blog entry creates a new page (with permalink) which is added to your sitemap, then you probably will need to educate your client on how to add it to the search database.

Ok, thanks Will. I’ll have to contact the client and see if they feel comfortable with this…if not, I’ll have to find another solution :slight_smile:

Sounds like we need a search stack that can rescan the sitemap on its own. If there was no extra work needed each time we publish it would be great. I use Google Custom search for this reason but it isn’t as nice as a built in search option that blends with the site better. We need a developer to solve this. I would buy it for sure!!!

@willwood TCMS builds its own “blog-sitemap.xml” file, if this file and it’s location are referenced in a main sitemap index file, would RapidSearch Live find it and the blog contents? Or does RapidSearch Live only look at a single sitemap.xml and can’t use an indexed sitemap file?

I tried a quick test referencing the location of the TCMS blog sitemap, including renaming it to “sitemap.xml” but didn’t work as hoped.

Agreed! :slight_smile:

How much would you be willing to pay? Lots of people want stacks that do X, Y, or Z but go quiet when the subject of money comes up! Any stack that starts down a route of running automated CRON jobs on the server or suchlike is leaving the normal RapidWeaver consumerbase and going far more technically advanced. So naturally the price tag would have to reflect that.

But is this a genuine sitemap you see in your FTP software or a fake one that gets generated on the fly dynamically with PHP or similar? Any physical sitemap file that passes XML validation tests should work. Whereas anything generated server-side probably cannot be seen or used.

Rapidsearch Live has a bias towards using the sitemap that RapidWeaver generates. Because in my experience, that is the one just about everyone uses all the time. The option of using another sitemap exists, but the success will depend on how it’s generated and its syntax quality.

I am not dissing the work you guys have done. I use Rapidsearch on a site as well. I do think people are shortchanging RW though. It is a very capable website builder and should be used by more people. I would be willing to pay $50 for a search solution that auto-generated the search data. Maybe it should be a plugin page instead of a stack. Perhaps a plugin could generate the search data when RW publishes rather than looking at a sitemap?