Questions to Ask a Long Island Web Designer

The same word—“website”—can describe very different scopes, responsibilities, ownership terms, and levels of support. The best time to clarify those differences is before work begins.

These are the 15 questions I would ask any web designer—including me—before signing a contract. The goal is not to catch someone out; it is to make the working relationship, deliverables, and tradeoffs understandable.

Setup and ownership

1. Will I own the website outright when this is done?

Ownership is not one yes-or-no item. The domain, original content, final design, source code, hosting account, platform license, fonts, stock media, and third-party services can all have different terms.

Ask for a written list of what you own, what you receive, what remains licensed, and what happens if the relationship or subscription ends. A hosted platform may not transfer its underlying code; that can still be acceptable when the limitation is understood before signing.

2. Where is the site hosted, and is the hosting account in my name?

Developer-managed hosting can be a legitimate service, but it creates a dependency that needs clear exit terms. Ask who owns the account, who pays the provider, who can access DNS and deployment settings, what support is included, and how the site would be moved if needed.

A modern static site might use Cloudflare Pages, Vercel, Netlify, or another suitable host. Confirm that the selected plan permits the business use, what limits and paid services apply, whose account owns the deployment, and how the site would be exported or moved.

3. What platform is the site built on, and why that one?

If the answer is “WordPress,” ask why it fits the project, which plugins are required, and who owns updates, backups, security, and hosting. Its editing tools and ecosystem can be valuable; the maintenance responsibilities should simply be explicit.

If the answer is “Wix” or “Squarespace,” ask which plan is required, what can be customized, how performance will be managed, what SEO controls are available, and what can be exported if you leave. Those platforms can fit some projects; the important part is understanding their specific limits and recurring costs. I’ve written a full comparison here.

If the answer is something custom (Astro, Next.js, plain HTML/CSS) — ask what specifically they’ll use and what the implications are for editing later. Some custom platforms require a developer to make changes; others let you edit content yourself.

4. Can I edit the content myself after launch, or do I need to come back to you?

Some sites are wired up so you can edit text, swap photos, and add blog posts yourself through a CMS. Others require a developer for any change.

Neither is wrong — but you need to know which you’re getting. If you’ll edit weekly, you want a CMS. If you only update once a year, paying a developer for those updates is fine.

5. What happens if I want to leave?

Will the designer hand over the code? The DNS settings? The hosting login? In a clean, organized way?

A useful answer identifies the exportable files, accounts, credentials, repositories, DNS records, licenses, documentation, timing, and any offboarding fee. The exact handoff depends on the platform, but it should not be improvised after cancellation.

Technical and SEO

6. What will my Google PageSpeed score be on launch day?

A responsible developer should explain the performance target, how it will be tested, which pages and devices are included, and how hosting, media, fonts, and third-party scripts affect the result. A fixed score promised before the final content and integrations exist is not meaningful.

You can inspect representative pages at pagespeed.web.dev, but a single score is not a verdict on the provider or a prediction for another project. Compare mobile and desktop results, repeat the test, look at the underlying diagnostics, and ask what content or third-party services affected the page.

7. Will the site rank for “[my service] [my town]” queries?

Honest answer: no provider can promise a position or timetable. A new or redesigned page may take time to be crawled and evaluated, while an established site may already have useful visibility that needs to be protected. Results depend on relevance, competition, technical quality, content, authority, real-world business signals, and search-engine decisions.

The right answer is something like: “I’ll handle the on-page side — titles, schema, structure, content depth — and walk you through the off-page side. No responsible provider can promise a position or timetable; search visibility depends on technical quality, content, competition, authority, and search-engine decisions.”

8. Will I be able to track who visits my site and where they come from?

You want Google Analytics 4 set up properly — not just installed but configured with conversion tracking for phone clicks, form submissions, and email clicks. Without that you’re flying blind on whether the site is working.

Google Search Console should also be connected and verified. It reports indexing information, search queries, pages, countries, devices, and other useful search data after Google has collected enough activity.

9. What schema markup will the site have?

Schema is machine-readable context that can help search engines understand the organization, services, articles, and other content on a website. The right type depends on what the page actually represents. An online or service-area business can use accurate Organization and Service markup without publishing a private home address or inventing a storefront. Structured data should describe visible, current information—not add claims solely for search engines.

The provider should understand when structured data is relevant, how it must match visible content, and why adding every available schema type is not a strategy.

Content and design

10. Who writes the content?

Content is a common project dependency, so pin down the responsibility explicitly:

• If the designer is writing it: how many revision rounds, and what’s the cost?
• If you’re writing it: when does it need to be done by? What format do they need it in?
• If you’re collaborating: who owns the first draft?

11. Whose photos are these going to be?

Generic stock photography can weaken a small-business website when it hides the real people, place, craft, or work customers want to evaluate. Original photography is usually the strongest evidence; carefully chosen supporting imagery can still be useful when it is honest and contextually appropriate.

Ask whether the provider can plan or coordinate photography, whether a separate photographer is needed, what usage rights are included, and who is responsible for scheduling, shot lists, releases, selection, and editing. Pricing varies by location, experience, deliverables, licensing, and production needs, so request a current quote rather than relying on a universal range.

If a designer’s portfolio is full of stock photos, that’s the look you’ll get.

12. How will the site be tested across phones, tablets, and browsers?

For many small businesses, phones represent a significant share of visits, but the actual mix varies by audience and should be checked in analytics when available. Ask to use representative live pages on a real phone—not only view screenshots.

Look for readable text, stable layouts, comfortable tap targets, useful forms, and navigation that does not depend on hidden gestures. If something behaves poorly, ask whether it is a current defect, a client-side change, or a limitation relevant to your project.

Legal and contract

13. What’s the deposit, and what’s the cancellation policy?

Payment schedules vary with project size, duration, procurement requirements, and the provider’s business model. Deposits, milestone payments, retainers, and subscriptions can all be reasonable when the terms and deliverables are clear.

What you want to avoid:

• A payment schedule with no corresponding scope, milestone, or cancellation language
• A subscription whose term, ownership, export, and cancellation consequences are unclear
• Vague revision language that leaves both sides unsure what is included

14. What’s covered after launch — and for how long?

Post-launch terms vary widely. Ask what counts as a defect, how long the correction period lasts, what routine changes cost, whether ongoing care is optional, and how urgent problems are handled.

Get this in writing. The most common post-launch friction is “I thought you’d fix that for free” vs “that’s outside the warranty period.”

15. Can I see proof of three live client sites and contact two of them?

Ask for relevant work, references when appropriate, and an explanation of what the developer personally contributed. A useful answer connects the business problem, the decisions made, and the delivered result.

A provider may need client permission before sharing contact information, and some work may be confidential. What matters is whether they can provide relevant evidence, describe their contribution accurately, and handle references with the client’s consent.

---

My answers

For the record, here’s how I’d answer all 15:

1. Ownership is written down. The proposal identifies the final code, design, content, accounts, licenses, and handoff materials included in your project.
2. Hosting and domain control are documented. Whenever practical, the important accounts are created in your name or transferred through an agreed handoff.
3. The stack follows the job. I commonly use Astro for content-led sites and React-based tools for app-style products, but the decision is based on the project.
4. Editing is decided before the build. Content can be maintained through an agreed editing system, through Website Care, or through a documented update process.
5. Offboarding is planned. Credentials, repositories, deployment details, and responsibilities are recorded instead of left to memory.
6. Performance evidence needs context. Ask for a date, representative pages, the device or test profile, and the conditions under which a result was recorded.
7. Search foundations are part of the website plan. Deeper local-search or ongoing content work is scoped separately when needed.
8. Measurement is discussed before launch. Analytics, Search Console, and useful conversion events should match what the business actually needs to learn.
9. Structured data must be accurate. The schema should describe the real organization, services, content, and service area without inventing an address or office.
10. Content responsibilities are explicit. We decide who supplies source material, who drafts the copy, and how review and approval work.
11. Real photography is preferred. When it is not available, we make a deliberate plan rather than filling the site with unrelated stock imagery.
12. Mobile behavior is designed and tested. Representative pages, navigation, forms, and interactive features are checked at phone sizes.
13. Payment and cancellation terms belong in the proposal. The schedule should fit the project and explain what happens if scope or timing changes.
14. Post-launch support is defined in writing. The project agreement records the correction period, and ongoing Website Care is available when appropriate.
15. Relevant case studies and references are available. Client introductions are made only with the client’s permission.

If you want to hear those answers in conversation, drop me a line and we’ll set up a call. You can also review the small-business website cost guide before requesting a written quote.