When to refresh rather than start from scratch

If your website already exists, it holds something valuable a new one won’t have: texts, photos, the logo and — most importantly — your Google rankings.

It’s worth refreshing if you recognise at least two of these:

• it looks bad or loads slowly on a phone;
• it was built long ago and nobody looks after it (especially if it’s WordPress with old plugins);
• there’s no padlock (HTTPS), or the browser shows a warning;
• you can’t find yourself on Google for your own service;
• the only person who can edit it is someone whose phone number you no longer have.

In an hour we’ll make a secure, fast and findable version — using what you already have. The AI will do most of the work. Your job is to approve, check, and do the last step: switching the domain.

What you need to start

1. An AI chat — ChatGPT, Claude, Gemini or Copilot. Ideally one that can read websites and create files.
2. A GitHub account — for the new site’s files and version history.
3. A Cloudflare account — for hosting. You can sign in to both with a Google account.
4. Access to your domain settings — wherever your domain is registered. You’ll only need it at the end.

Two things that matter especially when refreshing an old site:

• Switch on MFA on the accounts you’ll use to manage the domain and the site. They become the key to everything. How — in the lesson Passwords and MFA without the pain.
• Use a company account, not a personal one. The most common problem we see at clients: the domain was registered ten years ago with someone’s personal email, and now nobody can take it over. If that’s already happened — the first job isn’t design, it’s getting the domain back.

A ready-made prompt: start with this

Copy this, fill in the square brackets and paste it into an AI chat. The most important part is the first step: the AI reads what you have before it builds anything.

You are carrying out my website refresh. I have an old website that needs to
become fast, secure and findable — without losing anything.

CONTEXT
- Old website: [https://yourcompany.lt]
- Company and what it does: [in one sentence]
- What I want from a visitor: [a call / an enquiry / an order]
- What I don't like now: [e.g. slow, looks bad on phones, outdated texts]

PROCESS — very important
0. TOOLS. First tell me what you can do yourself: read websites, create files,
   use a terminal, control a browser, connect to GitHub or Cloudflare.
   Say straight away what you can't.
1. INVENTORY. Read the old website: every page and its address, the texts,
   photos, logo, contacts and company details. Show me the list and wait for
   my approval. Don't build anything until I approve.
2. ASK. Ask me the missing questions, one at a time.
3. PLAN. The new structure — separate pages: home, services, about us,
   contact — and a table "old address → new address" for every old page.
   Ask whether it works for me.
4. DO. Build only once I agree.

GOAL — a working new site on a temporary address, not files on a computer
- Create a private GitHub repository, add the files, connect Cloudflare Pages
  and publish. The job is finished when the new site works at a *.pages.dev
  address.
- DON'T switch the domain — I'll do that once I've checked everything.
- If you need my sign-in or permission — tell me exactly what to click,
  wait until I confirm, and CONTINUE the work.

SEARCH RANKINGS
- For every old address that changes, add a 301 redirect to the _redirects file.
- Keep or improve every page's title and meta description.
- Add sitemap.xml, robots.txt and llms.txt.

RULES
- INVENT NOTHING. Use my real texts, photos and contacts. You may tidy the
  texts, but don't change the facts. If a fact is missing — ask me.
- Shrink photos to ~200 KB, up to 1600 px wide.
- Read only the public website. Never ask for the old site's admin or hosting
  passwords.
- Talk to me in English; keep the site in its current language unless I say otherwise.

AT THE END
Tell me: the new address, what was moved, the list of redirects and separately —
WHAT YOU DID NOT CHECK.

If the AI still stops at the files and only offers to publish — that’s the most common snag, described in the lesson Build a new website in 1 hour. Write: “Don’t stop. The goal is a working *.pages.dev address. Where you need my sign-in — tell me what to click, wait and continue.”

What the AI doesn’t get

The AI reads your public website — the same thing any visitor sees. That’s enough.

It never gets the old site’s admin, hosting or domain passwords. When you need to sign in to GitHub, Cloudflare or your domain settings, you click: the agent asks for permission and you confirm in your own browser. Why — in the lesson How to start using AI at work (safely).

Step one: the inventory

Before you touch anything, gather what’s yours. Everyone skips this step — and pays dearly for it later.

Old, poor-quality photos? You can fill the gaps with AI-generated backgrounds or illustrations — but don’t replace your real work, premises and people with AI images (more in Build a new website in 1 hour).

And one more tip from experience: don’t throw out all your old texts. They often hold specifics (towns, deadlines, product names) the AI won’t come up with — and it’s exactly those specifics that bring clients in.

Don’t lose what you’ve already earned

Google shows not websites but addresses. If the page yourcompany.lt/services was in fifth place and the new site no longer has that address, someone clicking the Google result sees a “page not found” error. After a while Google drops that result — and fifth place simply disappears. A 301 redirect tells browsers and Google “this page has moved here permanently” — and the value it has built up moves with it.

Two safe routes:

1. Keep the same addresses. The simplest and most reliable.
2. If an address changes — a 301 redirect from the old to the new.

For the same reason, don’t squash the whole site into one page. Google and AI search show pages, not websites — every page you have is a separate chance to be found.

This is what the file looks like:

/kainorastis       /prices        301
/apie-imone        /about-us      301
/index.php/kontaktai  /contact    301

Speed: usually it’s the photos

One 5 MB photo takes longer to load on a phone than the whole rest of the page. The prompt already tells the AI to shrink photos to ~200 KB. Doing it by hand? squoosh.app — free and works in the browser: up to 1600 px wide, WebP format if offered.

Want a new look too? Design tools such as Google Stitch can suggest several options. But it’s not required — speed, content and addresses matter more than design.

Security: why a static site is calmer

An old WordPress site with unmaintained plugins is the most common way a small company’s website starts spreading someone else’s ads or viruses. The problem isn’t WordPress — it’s maintenance.

A static site (plain HTML files) has no such risk by design: no admin login, no plugins, no database, nothing to break into. And you get a free HTTPS padlock that switches on automatically.

Publishing next to the old site — on a temporary address

The new site first goes to a temporary address, e.g. your-company.pages.dev. Meanwhile the old site keeps working as before — visitors don’t see unfinished work.

Why via GitHub rather than just uploading the files — every change is saved, and any version can be restored. More in Build a new website in 1 hour.

Switching the domain — last, and reversible

This is the only step visitors will notice. So you do it yourself, once everything has been checked, and in a way that lets you go back at any time.

Before switching:

• The new site on its *.pages.dev address has been checked on a phone and a computer: texts, contacts, links, redirects.
• Take a screenshot of the current DNS table in your domain settings. That’s your way back.
• Check where your email runs. If your email runs through the same hosting — don’t cancel the hosting until the email has been moved.

When you change nameservers, Cloudflare copies the existing DNS records. Before you confirm, compare them with your screenshot — especially the MX and TXT records. If they’re missing, email will stop working after the switch.

After switching:

• Open the domain on a phone and a computer: does the new site open, with a padlock?
• Open a few old addresses from the inventory: do they redirect?
• Send and receive an email: does email work?

If something’s wrong — go back. In the DNS table, restore the old record from your screenshot: the old site is still running, so within a few minutes visitors see it again. Keep the old hosting for at least a few weeks, until you’re sure everything is fine.

So you’re found — by people and by AI

The prompt already tells the AI to add sitemap.xml, robots.txt and llms.txt — the first two help Google, the third helps AI systems understand who you are. But what you write matters most:

• title: “Service in city | Company” — exactly how people search.
• description: one sentence shown in Google’s results.
• Specific text. AI search (ChatGPT, Perplexity, Google AI) reads the same text as a person. “We repair computers in Kaunas and arrive within 4 hours” works better than a list of keywords.
• Contacts and company details clearly visible — both Google and clients value that.
• A Google Business profile — for a small business often more important than the website itself.

What to check before saying “done”

• It opens on a phone and a computer, and the text is readable without zooming.
• The phone number can be tapped.
• Every old address from the inventory works or redirects.
• There’s a padlock (HTTPS).
• Email works — both sending and receiving.
• Company details in the footer; a privacy policy if there’s a contact form.
• site:yourcompany.lt still shows your pages a week later.

Don’t want to do it yourself, or the site is more complex? pagalba@itbroliai.lt

Check yourself

Five questions on what you’ve just read. At the end you’ll get a certificate with your score.