If you built your site two or three years ago and haven't touched it since, you're not alone, and you're not automatically in trouble either. Some owners panic the moment they hear "outdated website" and assume they need a full rebuild. Others ignore the warning signs for years and end up with a plugin conflict that takes their checkout page down on a Saturday.
The honest answer is that "update your website" doesn't mean one thing. A security patch, a blog post, and a homepage redesign all run on completely different schedules, and treating them like the same task is how sites end up either neglected or over-managed. By the end of this, you'll know which updates can't wait a week, which ones are fine to batch monthly, and which ones you can genuinely leave alone for a year or two.
Not All 'Updates' Mean the Same Thing
Here's where most owners get stuck: they hear "update your website" and picture one giant task, so they either do nothing or they do too much. In reality you're dealing with three separate jobs that run on three separate clocks, and lumping them together is how you end up either overspending or getting hacked.
Technical maintenance is the one with no wiggle room. Plugin updates, CMS core updates, SSL certificate renewals, backups — this stuff needs attention weekly or monthly depending on your platform, not whenever you get around to it. Skip a plugin update for six months and you've got an open door for malware. This is the layer most business owners don't even see happening, which is also why it's the one that gets neglected first.
Content updates move slower and follow your business, not a calendar. Pricing changes, new hours, a service you stopped offering last spring, testimonials that are three years stale — these need refreshing every few months, or whenever something in your business actually changes. There's no fixed schedule here, just a rule: if the page says something that isn't true anymore, it's overdue.
Redesigns are the long game. Years, not months, and they're triggered by your brand feeling dated or your conversion rate sliding, not by the fact that it's "been a while." If you're not sure whether a refresh will hurt the rankings you've already built, it's worth reading up on how to protect your Google rankings during a website redesign before you touch anything structural.
A common mistake: an owner notices their site "feels old" and jumps straight to budgeting a full redesign, when what they actually needed was a security patch and a new pricing page. That's a few hundred dollars of work being mistaken for a five-figure project.
What Happens When Each Type Gets Ignored
Skip security updates and you're not looking at a certainty, you're looking at a probability that climbs every month you wait. Picture a service business whose site runs outdated plugins for a year straight. It might run fine the whole time. Or it might get flagged by Google as unsafe, start throwing warning screens at visitors, and quietly drop out of search results while nobody at the company notices until a customer calls asking why the site looks broken. The business cost isn't really the hack itself. It's the trust you lose when a customer sees a red warning page, and the days of downtime while someone cleans up the mess.
Content neglect works slower but it's almost guaranteed to cost you something. A services page listing 2019 pricing, a blog that stopped posting three years ago, an "our team" page with employees who left last spring. None of that crashes your site. It just makes you look closed, or careless, and Google notices the staleness too. Rankings erode a little at a time, which is almost worse than a sudden drop because you don't see it happening.
Design neglect is the one you can live with longest. A dated layout next to a competitor's sharp new site hurts conversions and makes you look behind the times, but it's rarely urgent on its own. Outdated fonts and layouts usually aren't a security problem, just a conversion one.
Your tolerance for risk should track with what your site actually does. A brochure site for a local service business can absorb a few months of delay. A site processing payments or storing customer data can't, and that gap is worth factoring into any maintenance plan you're considering.
A Simple Schedule You Can Actually Follow
Here's a baseline you can hand to yourself or to whoever manages your site. It's not gospel, it's a starting point you adjust once you know your own traffic patterns and how often your business actually changes.
Security updates and backups: weekly for active eCommerce sites, monthly minimum for a simple brochure site that doesn't take payments
Plugin and software updates: monthly, or immediately when a critical patch drops
Content updates (pricing, hours, staff bios, blog posts): quarterly, or whenever something in the business actually changes
Full design refresh: every 2 to 4 years, or sooner if your conversion numbers are tanking or your brand has moved on without the site
A static five-page site for a local tax preparer doesn't need the same attention as a 200-product online store with a checkout flow and customer accounts. More moving parts means more that can break, so the eCommerce site probably needs weekly eyes on it while the tax prep site can get away with monthly check-ins and call it done.
Seasonal businesses throw this off in a good way. A landscaping company might need content touched four or five times a year, not once, because spring cleanup pricing and fall leaf removal specials actually matter to what shows up on the page. If your business shifts with the calendar, let that shift your content schedule too.
A common trap: owners set a calendar reminder to redesign "every three years" like it's an oil change. Design should get triggered by what the data tells you, not a date on a calendar. If your bounce rate is climbing or your site still looks like 2019 next to competitors, that's the signal, not the anniversary of your last launch. Redesign budgets vary a lot depending on site complexity and scope, so it's worth getting a sense of your own maintenance and support options before you price out anything bigger.
How to Tell If Your Site Is Overdue Right Now
Run through this yourself, right now, before you call anyone. You don't need a developer to spot most of these.
Can you log into your CMS or admin panel without resetting a password you forgot you had?
Do you know the date of your last backup, off the top of your head?
Does your site load in under three seconds on your phone, using regular cell service, not wifi?
Have you clicked through your own main menu and contact form in the last three months?
Does your footer still say a copyright year from two or three years ago?
Has anyone added a blog post, service update, or new photo in the last six months?
If you search your own business name, does the listing match what's actually on the page?
One or two "no" answers isn't an emergency. Businesses get busy, copyright years slip, nobody updates a blog every month and that's fine. But if you land on three or more, you're overdue, not eventually, now.
Here's the part that trips people up: a site can look completely fine and still be sitting on real technical debt. Clean design, nice photos, everything loads, and underneath it you've got six plugins nobody's touched since install, a backup system that silently stopped running eight months ago, and a login you haven't used since the person who built the site handed it off. The visual layer and the technical layer break independently. You can have a beautiful homepage sitting on a security hole, and you'd never know by looking at it.
If this check just made you nervous, that's useful information, not a reason to panic. It just means it's time to get someone to actually look under the hood, whether that's through a website management service or a straightforward maintenance plan built around what your site actually needs.
Why Most Owners Outsource This Instead of Managing It Alone
If you went through that checklist and found two or three things you can't answer, that's not a crisis. It's just information. Some businesses genuinely don't need a maintenance package yet. A simple five-page site for a one-person operation, no online booking, no payment processing, updated maybe twice a year, doesn't justify a monthly contract. You can log in once a month, click "update" on your plugins, and move on with your day.
Where it stops being a DIY job is the moment your site starts handling things that cost you real money if they break. Online bookings, payment forms, customer accounts, anything storing someone's name, email, or card details. At that point an ignored update isn't just a cosmetic risk, it's a liability risk. Same goes for your time. If you're the owner doing the books, managing staff, and talking to customers, the hour you spend wrestling with a broken plugin update is an hour that costs more than what a maintenance plan would run you.
Here's the honest trade-off, no sugarcoating it either direction: doing it yourself saves money right now, but you're betting that you'll actually remember to do it, and do it correctly, every single month, for years. Miss that bet once and you're looking at a hacked site, a lost weekend, and a developer bill that's bigger than a year of maintenance would've cost. Paying for a managed plan costs more upfront, but it takes the task off your plate entirely, and that's worth something if you've got a business to run. If you're weighing what that actually costs against what you're paying a designer for other work, it helps to see current rates for web design and maintenance work side by side before you decide.
What to Ask Before You Commit to a Maintenance Plan
Once you've decided you want someone else handling this, the next mistake is signing up for the first plan you find without checking what's actually inside it. A lot of "maintenance packages" are really just hosting with a nicer name. Your site stays online, uptime gets monitored, and that's it. Nobody's touching your plugins, nobody's watching for malware, nobody's making the homepage edit you emailed about three weeks ago.
Before you sign anything, ask the provider directly:
Does this plan include plugin and core software updates, or only server uptime monitoring?
How often do you run backups, and where are they stored, separate from the live site?
Is malware scanning and cleanup included, or billed separately if something gets infected?
How many content changes or edits are included per month, and what counts as "included" versus extra?
Do I get any kind of report showing what was actually done each month?
That last one matters more than people expect. If you're paying monthly, you should be able to see what you're paying for, not just trust that it's happening somewhere in the background.
Match the plan to the schedule you actually need, not the one that sounds most impressive. A simple service site that gets updated twice a year doesn't need the same plan as an online store processing orders daily. Buying the top-tier package because it sounds safer usually just means paying for monitoring frequency you'll never use. And if your business operates in multiple service areas, ask whether content updates cover things like building out a separate page for each city you serve, since that's a common gap in Basic REDACTED.
You've now got a real schedule and a real set of questions instead of a vague sense that your site is "probably fine." Take a look at our website maintenance packages to see which tier actually matches the update frequency your site needs.
Frequently asked questions
How can I tell when a website was last updated?
Check the footer for a copyright year or "last modified" date, though plenty of sites skip this. A faster check: look at the blog or news section for a posting date, scan pricing or team pages for anything that reads stale, and run the site through your browser's dev tools to see the page's last-modified header. If none of that is current, assume the back-end hasn't been touched either.
What happens if I don't update my browser, and does that affect my website?
That's a separate issue from site maintenance, but the logic is identical. An outdated browser stops getting security patches, which leaves known vulnerabilities open for attackers. Your website works the same way: skip plugin and CMS updates long enough and you're running software with documented holes that malware scanners actively look for. Weekly or monthly patching is what keeps either one from becoming an entry point.
Do I still need a website if my business runs mostly on social media?
Yes, and keeping it current matters more than having it exist. Social platforms don't give you control over your pricing page, your SEO, or what happens if the algorithm buries your posts. A site with correct hours, services, and testimonials still does the trust-building work social media can't, but only if it doesn't say something about your business that's no longer true.
What are the basics every website needs to get right?
Security, accuracy, and speed cover most of it. That means current plugins and a valid SSL certificate, content that reflects your actual pricing and services right now, and a design that doesn't make visitors wait or guess where to click. Miss the first one and you risk getting flagged as unsafe. Miss the second and you look closed or careless. The third mostly affects conversions, not safety.
How urgent is a plugin or CMS update when I see one pop up?
Depends on what it's patching. A routine version bump can usually wait for your monthly maintenance window. A critical security patch, the kind that closes a known exploit, needs attention within days, not weeks. If you're not sure which one you're looking at, treat it as urgent. An open plugin vulnerability sitting for months is how checkout pages go down on a weekend with zero warning.
We get asked how much a Divi website costs almost every week, and the honest answer depends on things most quotes never spell out. One business owner gets a quote for $900. Another gets $12,000 for what looks like the same Basic REDACTED-page site on paper. Neither number is wrong. They're pricing completely different scopes of work, and nobody's explaining that upfront.
Here's the part that trips people up: Divi itself is cheap. A yearly Elegant Themes license runs around $90, or you can pay a few hundred once and use it forever. So when a designer quotes you $8,000, you're not paying for the software. You're paying for their time, their strategy work, custom design instead of a template, and whatever integrations your site needs to actually run your business. Once you see where that money goes, comparing quotes gets a lot easier.
Basic REDACTED-based sites: roughly $800–$2,500
Custom-designed small business sites: roughly $3,000–$7,000
WooCommerce or eCommerce builds with product setup and payment integration: roughly $4,000–$10,000
Custom-heavy sites with complex integrations, animation, or multi-location needs: $10,000–$20,000+
What a Divi Site Actually Costs in 2026
That Elegant Themes license isn't what you're actually paying for when you hire a Divi web designer. The real cost is labor — time spent planning your site, building it, writing or editing your copy, setting up SEO basics, and testing it on an actual phone before it goes live. Separate those two things and quotes start making a lot more sense.
Rough bands we see in the market right now, for a typical local business:
DIY-assisted setup (you build it, a designer helps with structure or a few fixes): $300–$900
Small brochure site, 5–8 pages, one round of revisions: $1,500–$4,000
WooCommerce or eCommerce build with product setup and payment integration: $4,000–$10,000
Custom-heavy design with animation, custom modules, or a larger multi-location site: $10,000–$20,000+
None of those numbers include hosting, which usually runs $15–$60 a month depending on traffic and whether you need managed WordPress hosting. Plugins for forms, SEO, backups, or booking systems can add another $10–$40 a month, sometimes more for anything specialized. Ongoing maintenance — updates, security monitoring, backups — is often a separate line item that gets left off the initial quote entirely, then shows up as a surprise three months in.
If a quote comes in dramatically under these ranges, ask what's actually included. Very cheap builds are almost always a stock template with your logo dropped in, no real content strategy, and no SEO setup beyond the default plugin settings. That might be fine for a placeholder site. It's not the same product as a site built to bring in calls and sales.
Why Two Divi Websites Can Cost So Differently
The $900-versus-$12,000 gap almost always comes down to four things: how many pages you actually need, whether the design is custom or built from a pre-made layout pack, how complicated your eCommerce setup is, and who's writing the content that fills the site.
Page count is the easy one to understand, but it's rarely the biggest swing factor. A pre-built Divi layout, dropped in with your logo and photos swapped in, can look decent and cost very little. Custom design — someone actually planning your layout around how your specific customers browse and buy — takes more hours and more thinking. Both get called "Divi websites." They're not the same product, and pricing them like they are is where a lot of business owners get confused comparing quotes.
eCommerce complexity moves the number a lot. A five-product catalog with flat-rate shipping is a different job entirely from a 200-SKU store with variants, tax rules across states, and inventory synced to a POS system.
Content is the other quiet cost driver. Hand over finished copy and photos, and you're paying for build time only. Need someone to write your service pages? That's additional hours, and it should be.
Revision rounds matter more than people expect, too. Designers who've done this a while build in time for strategy calls and troubleshooting, not just clicking around in the builder. That planning time is part of what separates a rushed template flip from careful, structured work. It's also why SEO, email setup, or local search work sometimes get folded into the first quote instead of tacked on later. Retrofitting those pieces after launch often means redoing page structure or content that was never set up to support them, so for most projects it's worth pricing them in from the start rather than treating them as an afterthought.
Cheap Divi Design vs. Paying for Real Expertise
A freelancer working out of a pre-made Divi layout pack can hand you a decent-looking homepage in a weekend. What you're not getting is someone thinking about how a visitor on a phone actually navigates that page, whether your images are slowing everything to a crawl, or whether Google can even figure out what your business does from the page structure. That's the gap between a cheap build and someone who handles UX, mobile performance, SEO structure, and conversion as part of the job, not an afterthought.
Picture a local service business that goes with the cheapest freelancer they can find. The site looks fine in the demo. Six months later, the phone isn't ringing the way it used to, the site barely shows up for local searches, and mobile visitors are leaving fast. That's a common enough pattern in this industry that it's worth planning around, even before it happens to you. Now the business is looking at a rebuild on top of what it already paid.
Signs a cheap build is going to cost you twice:
Pages that take four or five seconds to load
No clear call to action above the fold
Heading tags that don't match how people actually search
Contact forms that don't work right on a phone
None of these show up on the surface. They show up in your traffic numbers a few months in.
Budget builds aren't always a bad call. A brand-new business testing an idea, with no real traffic yet and no urgency to rank locally, is often fine with something modest for a year while they figure out if the business works at all. The mistake is treating that same approach as fine for a company already competing for customers in a real market. At that stage, the labor and expertise behind a designer who understands more than the theme itself tends to pay for itself.
How to Budget for Your Divi Website Project
Before you ask anyone for a number, write down what you actually need. Not "a nice modern website" — an actual list. How many pages, roughly? Do you need online booking, a store, a membership area? Are you selling 20 products or 2,000? Designers can't give you a real quote off a vague description, and if they do, that number usually falls apart once they see what's actually being asked of them.
Separate the one-time build cost from what you'll keep paying afterward. Design and development is a single project fee. Hosting, plugin licenses, security monitoring, and maintenance plans are ongoing, usually monthly or yearly. If a marketing retainer is part of the deal — SEO, ads, email — that's a third bucket entirely. Lumping all three into one mental number is how business owners end up shocked six months in, still paying for things they thought were a one-time expense.
The mistake we see most often: budgeting for launch day and nothing past it. Sites need content updates, seasonal changes, security patches, the occasional redesign of a page that isn't converting. Stop your budget at "get it live," and you'll pay for every small fix piecemeal, at a worse rate than if it were built into a plan from the start.
A rough checklist before you go quote-shopping:
Define scope in writing — page count, features, eCommerce yes or no, product count if it applies
Separate one-time design costs from recurring hosting, maintenance, and marketing costs
Request itemized quotes, not a single lump-sum number, so you can see what you're actually paying for
Build in a buffer, usually 10–15%, for revisions or scope you didn't think of at the start
Then get two or three quotes based on that same written scope, not three different phone calls where each designer heard something slightly different. It's the only way to compare apples to apples instead of guessing why one number is triple another. If you want a sense of what's actually included in a full-service build, our Divi web designer page breaks down what we typically scope into a project like this.
Questions to Ask Before You Hire a Divi Designer
Once you have a budget range in mind, the next filter is asking the right questions before any deposit changes hands. A fair-priced designer can walk you through their quote in terms of what you're actually getting — this many pages, this level of custom design, this much revision time — not just "40 hours at our rate." If someone can't explain the number that way, that's worth pausing on regardless of whether the total is $1,200 or $9,000.
Vague answers about timeline or scope are the bigger red flag, bigger than a high price tag. "It depends" is a fine start to an answer. "It depends" as the whole answer, with nothing about how they'd narrow it down, usually means they haven't thought through your project yet, or don't want to commit to anything measurable.
Before you sign anything, ask:
How many rounds of revisions are included, and what happens if I need more than that?
Do I own the site files, the domain, and the Divi license, or does the designer keep control after launch?
What's included after the site goes live — bug fixes, a warranty period, or nothing at all?
Who's responsible for writing SEO titles, meta descriptions, and page content, and is that in the quoted price or billed separately?
Is this a one-time project fee, or is there an ongoing monthly cost for hosting, updates, or marketing?
That last one trips up a lot of business owners. Some quotes are all-in for design and build, with hosting and maintenance billed separately once the site's live. Others bundle a year of support into the upfront number. Neither approach is wrong, but you need to know which one you're agreeing to before launch day, not after the first monthly invoice shows up unexpected.
Getting a Website That's Actually Worth the Investment
At some point you have to stop comparing quotes side by side and ask a different question: what is this site supposed to do for the business. A $4,500 site that brings in booked jobs every month is cheaper than a $1,200 site nobody finds or trusts enough to call.
We'd rather talk about your site as one piece of how you get found and get paid, not a standalone purchase you check off once. A homepage with no thought toward local search, mobile speed, or how your booking or checkout flow actually works isn't saving you money. It's costing you later, in the leads that bounce and the hours you spend fixing things yourself that a designer should've handled up front.
By the time you get on a call with us, you don't need a finished spec sheet. But bring the scope notes and budget range you worked out earlier — page count, whether you need eCommerce, roughly how many products, what's custom versus templated. That's enough for us to give you a number that actually holds up instead of one that falls apart once we open the hood.
If you want a straight answer on what your project would run, reach out through our Divi web designer page and tell us what you've got in mind. We'll walk through it with you before anything's decided.
Frequently asked questions
How much does Divi cost?
The Elegant Themes license itself is cheap: around $90 a year, or a one-time fee of a few hundred dollars for lifetime access. That's not what you're actually paying a designer for, though. When someone quotes you $3,000 or $8,000, that number covers their time, planning, custom design work, and any integrations your site needs. The license fee barely factors into the total.
Is Divi Lifetime worth it?
For most local businesses, yes, especially if you plan to build more than one site or expect to keep the same site running for years. It's a one-time payment instead of an annual renewal, so it pays for itself if you're past the two or three year mark with the theme. It matters less than people think when comparing designer quotes, since the license cost is a small slice of the total project price either way.
Is Divi better than Wix?
Divi gives you more design control and typically better long-term SEO structure, since you're on WordPress rather than a closed platform. Wix is easier for a true DIY build with no designer involved. If you're hiring someone to build the site for you anyway, Divi usually makes more sense, since it scales better into eCommerce, custom integrations, and multi-location setups without hitting a platform ceiling.
Which one is better, Elementor or Divi?
Both are solid page builders, and a lot of the "better" argument comes down to what your designer prefers working in. Divi tends to have a slight edge on built-in design flexibility and theme-level styling options, while Elementor has a huge plugin ecosystem. Neither choice moves your price much. What drives the cost is the scope of the build, not which builder your designer picks.
Why do two Divi websites end up costing so differently?
Page count is part of it, but the bigger swings come from custom design versus a pre-built layout pack, how complex your eCommerce setup is, and who's writing your content. A five-page brochure site with a stock template and your logo dropped in might run $900. A custom-designed site with original copy and a real content strategy behind it can run $5,000 or more, even with the same page count.
The decision isn't about reaching a magic number of pages. It's about whether each page gives someone a useful answer they wouldn't get as clearly elsewhere on your site.
Start with the customer's question
A person looking for a contractor, accountant, or repair service wants to know whether you can help them where they are. Sometimes a simple coverage statement answers that question. Sometimes they need more detail.
Think about a hypothetical company serving Orlando and nearby communities. If the same team provides the same service under the same arrangements throughout that area, a clear service page and coverage section may be enough. A page for every suburb could make the website bigger without making it more useful.
Now imagine the company has a separate staffed location with different opening hours, a different team, and services that aren't available elsewhere. A dedicated location page has an obvious purpose: it helps people understand and contact that location.
Service-area pages can also be useful without a physical office in each city. The important thing is to describe the arrangement honestly. Serving a place and being based there are not the same claim.
Use these three questions before creating a page
Before adding another city to the publishing queue, ask:
Do we actually provide the advertised service in this location?
What does a customer here need to know that isn't already clear on our main service page?
What accurate local information or evidence can we contribute?
The first question is essential. The other two help decide whether a standalone page is worthwhile. If the answers are weak, improve your existing service-area information first.
Useful local differences might include appointment arrangements, delivery coverage, project examples, a local team, or a clearly explained restriction. You don't need every type of detail. You do need a reason for the page to exist beyond inserting another place name.
Understand the difference between a helpful page and a doorway page
Google's spam policies on doorway abuse describe pages created to rank for similar searches while directing users through less useful intermediate destinations. They include examples involving multiple regional or city pages that funnel visitors to one page.
That doesn't mean every city page is prohibited, or that sharing a contact form makes a page a doorway. The concern is the purpose and usefulness of the pages as a whole. Can someone get a meaningful answer on the page they reached, or does it exist mainly to catch a variation of a search?
Don't try to solve that problem with a sentence about local weather, a landmark, or a city history paragraph pasted above generic sales copy. Those details may be unique, but they don't necessarily help someone choose your service.
Write for the customer standing in that location with a real need. If you can't explain how the page helps that person, more words won't create a stronger reason for it to exist.
What should a useful city page include?
Open with the service and the location, then explain the arrangement. Are customers visiting your office, or is your team traveling to them? Does coverage include the whole city or only part of the surrounding area?
Make the next step specific. Someone requesting an on-site estimate may need to provide a ZIP code and project details. Someone visiting a staffed office needs accurate directions, hours, and contact information.
Useful detail
Why it belongs
A real project in the area, shared with permission
Shows relevant work rather than merely claiming local experience.
Clear coverage boundaries
Helps someone determine whether you can serve their address.
Location-specific appointment arrangements
Sets realistic expectations about how the service works.
Accurate office information, where an office exists
Helps customers visit or contact the correct team.
Answers to questions customers from that area actually ask
Gives the page a practical purpose beyond repeating a service description.
Don't manufacture examples if you haven't completed a project there. Explain your actual coverage and service process instead. If a local requirement matters, verify it with the relevant authority before including it, and assign someone to keep that information current.
Customer reviews can support a page when they are genuine, relevant, and used appropriately. They shouldn't be rewritten to imply a different location or experience. Our article on getting local reviews may help you develop that evidence over time.
Don't invent an office to support a page
A city page does not require you to claim an address there. “We provide on-site service in Winter Park” is different from “Visit our Winter Park office.” Use the statement that matches reality.
Google Business Profile is also a separate system from your website's page structure. Adding a city page does not automatically make your business eligible for an additional profile. Check Google's business representation guidelines before creating profiles for additional locations, especially if you operate as a service-area business.
Be consistent about your business name, actual locations, and how customers reach you. A website that implies several staffed offices while the contact information describes one traveling team creates confusion before the first conversation.
Make the pages part of a sensible website structure
Useful pages should be easy to find through normal navigation and relevant links. A service-area overview can explain your coverage and link to the locations that deserve more detail.
Keep service information and location information connected. If someone lands on a city page about roof replacement, they should be able to learn about the replacement process without guessing which menu item contains it.
Avoid filling every footer with an enormous list of city-and-service combinations. Ask whether the links help readers navigate. A clear overview may be more usable than dozens of nearly identical labels.
This is where content planning and responsive website design meet. The structure has to remain understandable on a phone, not just look comprehensive on a desktop sitemap.
What if you already have dozens of similar pages?
Review them before deleting anything. Some may have useful links, search traffic, or inquiries attached to them. Others may contain details that should be preserved even if the overall structure needs simplifying.
Sort the pages into three practical groups: worth keeping and improving, better combined into a broader resource, or no longer relevant to what you offer. Compare the actual content and purpose rather than deciding from word count alone.
If you combine pages, plan what happens to the retired addresses. A relevant replacement may call for a permanent redirect; a page with no genuine replacement should not automatically send people to an unrelated homepage. Google's redirect guidance explains the technical options.
Make changes in a way you can review. Record which pages were changed and monitor both useful inquiries and search performance. Don't assume that fewer pages must improve results any more than you assume that more pages must improve them.
Build the next page only when it earns its place
Start with one important location. Gather the real questions, service details, and evidence you have for it. If those support a useful page, create it carefully. If they don't, make your main coverage information clearer.
Your website should explain where you work without pretending to be something your business isn't. If you're unsure which structure fits your coverage, our SEO services can help you assess the existing pages and plan a more useful local presence.
For a service business, the best approach is usually the most specific pricing information you can provide honestly. That might be an exact price, a starting price, a realistic range, or a clear explanation of how a quote is calculated. You don't have to publish a fixed figure for work that genuinely needs an assessment.
The aim is to help a suitable customer take the next step with realistic expectations. A number without context can mislead. No guidance at all can leave someone wondering whether contacting you is worth the effort.
Decide what your pricing information needs to do
Start with the conversations your business actually has. Do people regularly expect a service that costs far less than you can provide? Are suitable prospects worried about being pushed into a sales call? Does your team spend time explaining the same minimum project requirement?
Those are different reasons to improve a pricing page. You may want fewer unsuitable inquiries, better-informed prospects, or an easier first conversation. Define the problem before choosing a format.
Publishing prices isn't automatically a conversion improvement. It might reduce the total number of inquiries while improving their suitability. It might also reveal that your page hasn't explained the value of the work well enough. Judge the change against your business objective, not just the number of form submissions.
Choose a format that matches how you sell
Format
Useful when
What readers need alongside it
Exact price
The scope is consistent and clearly defined.
Inclusions, exclusions, and any conditions affecting the total.
Starting price
You have a genuine entry-level service or minimum project.
What that starting scope includes and what makes the price rise.
Price range
Jobs vary within an explainable range.
Examples showing why different projects fall at different points.
Individual quote
An assessment is needed before a responsible price can be given.
Cost drivers, the quoting process, and what the customer must provide.
You can combine these formats. A company might publish a fixed assessment fee and then quote separately for the work. Another might show a minimum project value while explaining that the final scope is individually priced.
The table is a decision aid, not a ranking of good and bad approaches. What matters is whether the visitor can understand how your particular service is priced.
Use exact prices when the boundaries are clear
A fixed price works best when customers can tell what they are buying. If a hypothetical cleaning company offers a defined service for a defined property size, the page can describe the included tasks, appointment length, and conditions that require a different quote.
Problems appear when the headline figure sounds complete but the scope is vague. Does the service include materials? Travel? A follow-up visit? Is it a one-time charge or a recurring payment?
Put those answers near the price. Don't make people assemble the real offer from the footer, a separate terms page, and an email they only receive after contacting you.
Be clear about how applicable taxes and unavoidable charges affect the total. Requirements vary by location and industry, so have your pricing presentation checked against the rules that apply to your business. This article is about communication, not a substitute for that review.
A starting price needs a meaningful starting service
“From” pricing can give prospects a useful point of reference. But the entry-level scope needs to be a genuine option, not a figure that almost nobody could qualify for.
Suppose a hypothetical design studio offers a small brochure website and more complex sites with booking tools, copywriting, or data migration. A starting price could make sense if the studio clearly explains the smaller package and the work that falls outside it.
Without that explanation, visitors may anchor on the lowest figure and feel surprised by a perfectly reasonable quote. The problem isn't necessarily the quote; it may be the expectation the page created.
Try reading the offer as a customer: “What could I actually receive for that price?” If the page can't answer, improve the scope description before making the number more prominent.
Make ranges useful with examples
A broad range can be honest and still be unhelpful. Saying a project could cost almost anything doesn't tell someone where their own needs might fit.
Explain the variables that matter. For a remodeling service, the layout, condition of the existing space, materials, and amount of structural work might affect the estimate. For a website project, page count alone doesn't capture integrations, content preparation, accessibility work, or migration complexity.
Use illustrative project descriptions to show the difference between a straightforward job and a more involved one. Clearly label hypothetical examples, and don't present them as completed customer projects.
If you describe a range as typical, support it with your own recent work and define the scope behind it. An old range copied from another website isn't evidence of what your business normally charges.
Review published figures when your costs or service packages change. Assign someone responsibility for the pricing page so that outdated information doesn't remain online simply because nobody owns the task.
If you need to quote individually, explain why
“Contact us for pricing” isn't wrong. It just leaves several questions unanswered. What information do you need? Is there a charge for the assessment? How does the customer get from the first inquiry to a usable estimate?
You can answer those questions without inventing a price. For example:
We price each project after reviewing the existing website, the content you need, and any booking or payment integrations. Send us your website address and a short description of the project so we can identify the right next step.
That is sample wording, not a statement of a particular company's terms. Adapt it to the process you actually follow, including any consultation fee or minimum project size.
Explain what causes prices to change and which information helps you prepare a quote. This gives the customer something useful even when the page cannot provide the final number.
Put the price beside the value, not in place of it
Customers need to understand what the service achieves and what the work involves. A price card can't do all of that on its own.
Describe deliverables in terms a buyer can recognize. “Monthly support” is vague. Explaining the included maintenance tasks, response arrangements, and limits gives someone a better basis for comparison.
Genuine examples, relevant qualifications, and an understandable process can support that explanation. Avoid unsupported claims such as “best value” or comparisons based on competitors' cheapest headline figures without matching the scope.
Your website content should help people assess the offer rather than overwhelm them with sales language. Clear pricing is part of that content, not a separate trick added to it.
Make the pricing page easy to use on a phone
Check the page on a small screen before deciding it's finished. Can a visitor read the differences between packages without scrolling sideways? Are important exclusions visible? Does the inquiry button clearly relate to the selected service?
A long comparison chart may work well on desktop but become exhausting on mobile. Sometimes a short description of each option is easier to understand than a grid full of checkmarks. Our guidance on website user experience is relevant here: the presentation should help readers complete their task.
Consistent pricing across the service page, downloadable proposal, advertisements, and checkout also matters. If those disagree, the customer has to decide which one to trust.
Test the result without chasing more inquiries at any cost
Before changing the page, record the question you're trying to answer. For example: will explaining the minimum project scope reduce inquiries for work we don't accept?
Then track a small set of useful measures:
How many inquiries are suitable for the service.
Which pricing questions people still ask.
How often suitable inquiries progress to a quote or booking.
Whether the work you win is profitable and appropriate for your team.
Compare reasonably similar periods and note other changes, such as promotions or a new advertising campaign. A before-and-after difference isn't proof that the pricing page caused it. For a small business with few inquiries, the reasons prospects give you can be as useful as a percentage based on a tiny sample.
Give customers the clearest answer you can stand behind
You don't need to reveal every internal calculation. You do need to give people an honest way to decide whether your service is a realistic option.
Choose one service page and review its pricing explanation today. Can a visitor understand the scope, the likely next step, and what might change the price? If not, those are useful improvements whether or not you add a specific figure.
If you're discussing a new site with a designer, make pricing and quote requests part of the brief. Our guide to hiring a website designer can help you prepare that conversation.
To protect your Google rankings during a website redesign, start by identifying what already brings visitors and inquiries to your site. Preserve useful content and working URLs where practical, plan redirects for addresses that must change, and test the new site before and after launch. These steps reduce avoidable problems; they don't guarantee that rankings will stay exactly the same.
If you've already decided a redesign is needed, this is the conversation to have before approving the new layout. Search visibility belongs in the project plan, not on a troubleshooting list after the site goes live.
Start with what the current website does well
It's easy to look at an old website and see only the dated colors, awkward navigation, or photos you meant to replace years ago. But a page that looks tired may still answer an important customer question and bring in worthwhile inquiries.
Before anything is removed, ask for a record of the existing pages and their performance. Which service pages receive search traffic? Which pages lead to calls or quote requests? Are there older articles or downloadable guides that other websites link to?
Google Search Console's Performance report provides clicks, impressions, click-through rate, and average position. Use those alongside your website analytics and inquiry records. Search clicks alone don't tell you which visitors became customers, and a low-traffic page may still answer an important question in the sales process.
Save a dated baseline covering a useful period for your business. If demand is seasonal, last month's results may not be a fair comparison for next month's launch. Record the dates of promotions and major campaign changes, too, so they don't get mistaken for redesign effects.
Keep useful page addresses unless there's a reason to change them
A new design doesn't require a new address for every page. You can improve the layout, images, navigation, and wording while keeping an established service URL.
For example, a hypothetical contractor with a useful bathroom remodeling page doesn't need to change its address just because the new menu says “Bathrooms.” Ask what a proposed URL change accomplishes. If the answer is simply that the new theme generates different addresses, that is worth discussing before launch.
When addresses do need to change, create an old-to-new URL map. Each old page should have an intentional outcome, not a blanket instruction to send everything to the homepage.
Situation
Planned action
The page still serves the same purpose
Keep its URL where practical and improve the page itself.
The page moves to a new address
Redirect the old address to its relevant replacement.
Two genuinely overlapping pages are combined
Keep their useful material and redirect the retired page to the combined resource.
The content is gone with no suitable replacement
Return a proper not-found or gone response rather than sending visitors somewhere unrelated.
Google's redirect documentation explains permanent redirects such as 301 and 308. Your developer should implement the appropriate response and test the destination. A visitor following an old service link should reach the corresponding service, not have to start their search again.
Redirects are also not a substitute for updating your own links. Once a page has moved, menus, buttons, and related articles should link directly to the new address.
Improve the content without losing the answers
Shorter isn't automatically clearer. A new layout may look cleaner after removing several paragraphs, but what did those paragraphs explain? Service areas, project requirements, turnaround times, and what happens after an inquiry can all matter to a potential customer.
Imagine replacing a detailed repair page with a photograph and the line “Solutions for Every Home.” It may look impressive, but someone trying to find out whether you repair their type of equipment has lost a useful answer.
You don't need to preserve every sentence. Remove outdated claims, repetition, and services you no longer offer. Keep the substance that helps readers decide whether you're a good fit. If a page needs substantial rewriting, give the writer its purpose, the questions it should answer, and the evidence supporting its claims.
That's one reason SEO should be built into web design from day one. The structure and the message need to work together. Trying to fit the missing information into the finished layout can create unnecessary compromises.
Don't let development settings follow the site into production
A development copy needs to be kept separate from the public website. Before launch, agree on how it's protected and who is responsible for checking the live site's settings.
One important distinction: blocking crawling with robots.txt is not the same as keeping a page out of Google's index. Google explains that a crawler must be able to access a page to see its noindex instruction. Private development sites should have appropriate access protection rather than relying on a robots.txt rule to keep them confidential.
At launch, the intended public pages must not retain development-only noindex instructions or access restrictions. Also check the canonical URL, which indicates the preferred address for a page. It should not still point to the staging domain. Google's canonicalization guidance explains how this signal works; it isn't a guarantee that Google will choose the nominated URL.
You don't have to inspect source code yourself. Ask your developer to demonstrate the checks on a service page, an article, and any other important page type. “We installed an SEO plugin” isn't an answer to whether those settings are correct.
Give launch testing a clear owner
Set aside time for testing instead of treating it as whatever fits into the last hour. Decide who can approve the launch, who handles unexpected problems, and how the previous working version could be restored if necessary.
A practical launch check should include:
Important old URLs reaching the correct pages, with no redirect loops.
Public pages loading successfully and using the intended indexing settings.
Navigation, internal links, images, and downloads working.
Contact forms, phone links, bookings, and checkout working where applicable.
Analytics and conversion tracking tested rather than merely copied across.
Mobile layouts remaining readable and usable on real devices.
A backup is useful only if someone knows what it contains and how to restore it. For a store or busy lead-generation site, the recovery plan must also account for orders or inquiries received after the backup was taken.
Keep major changes manageable. Google's site-move guidance recommends separating changes where practical and warns that significant moves can bring temporary ranking fluctuations. If the project also includes a new domain, new platform, and new copy, agree on a sequence rather than assuming one dramatic launch is simpler.
Watch what happens after launch
Check the live site immediately, then review it again as search and business data accumulate. Look at important pages individually, not just the sitewide traffic total. An increase in blog visits can hide a decline on a service page that matters more commercially.
If inquiries fall, test the form before assuming your rankings collapsed. If tracked traffic disappears suddenly, confirm the analytics setup. If specific old URLs return errors, check their mappings. Start with observable faults rather than guessing at an algorithm explanation.
Also update the sitemap to reflect the intended live URLs and review indexing information in Search Console. Submitting a sitemap helps discovery; it doesn't guarantee that every page will be indexed or rank. Google's sitemap overview makes that limitation clear.
Agree on a post-launch review period and responsibilities in advance. Ongoing website management can provide a place for these checks, but the proposal should say what is actually included.
Ask for the SEO handover, not just the finished design
Before signing off, ask for the final page inventory, redirect map, test results, access details, and a record of any unresolved issues. You should know what changed and whom to contact if a problem appears.
A successful redesign is more than a fresh look. It should preserve what was useful, correct what wasn't, and make the next step easier for your customers. If you're planning a project, our SEO services can help you bring search considerations into the discussion before launch.
