Building a Website Spell Checker with Laravel and GPT-4

I launched Site Spell Checker to check the content that's already on a website. Give it a URL, scan the pages, and get a report of spelling errors, grammar issues, and style suggestions.

A browser spell checker can help while you're writing. It isn't looking through all the pages you've already published. That's the job I built this for.

Getting the text first

The app has to fetch a page before it can check anything. The scraper gathers the title, description, headings, page text, links, and metadata. Then the spell checking service prepares the text and sends it to OpenAI.

The first version used GPT-4 Turbo with a proofreading prompt and a JSON response format. The application processes that response into issues it can show in a report.

Those are two different parts of the job. If the scraper doesn't get the useful text, the proofreading step isn't going to rescue it. JavaScript-rendered pages are another complication; support through a headless browser was on the list for later.

Making a scan something you can follow

The frontend uses Livewire, Blade, Tailwind, and Alpine. Submit a URL and email address, create a scan record, and follow it to the results. Queues handle background processing, and the UI needs to show what's happening while that work runs.

A failed request also needs to make sense to the person who submitted it. An inaccessible website and an AI API failure are different problems, even if both result in “the scan didn't work.” The service boundaries give the app places to handle those failures.

The results distinguish errors, warnings, and suggestions. That distinction matters for proofreading: a misspelling and a proposed style change shouldn't carry the same weight. You still need to read the suggestion in context before changing your content.

Keeping the build small

I used Laravel and SQLite for the application, with the OpenAI PHP client for the API integration. Laravel's queues, notifications, and rate limiting cover the surrounding work.

The initial product offered a free single-page scan and a paid full-site scan. Scheduled monitoring, custom dictionaries for brand names, ignore rules, and CMS integrations were ideas for the next versions.

Custom dictionaries are particularly interesting here. A product name can look like a spelling error, and the same name can appear on every page. Giving the checker that context would make the report more useful.

You can try a scan at sitespellchecker.com.